Per the urllib.parse documentation, username, password, hostname,
and port will be set to None if not set in the parsed URL. The
same is true for urlparse in Python 2 according to its documentation.
This pull request is a follow-up to https://github.com/python/mypy/issues/7214.
In short, within that mypy issue, we found it would be helpful to
determine between contextmanagers that can "swallow" exceptions vs ones
that can't. This helps prevent some false positive when using flags that
analyze control flow such as `--warn-unreachable`. To do this,
Jelle proposed assuming that only contextmanagers where the `__exit__`
returns `bool` are assumed to swallow exceptions.
This unfortunately required the following typeshed changes:
1. The typing.IO, threading.Lock, and concurrent.futures.Executor
were all modified so `__exit__` returns `Optional[None]` instead
of None -- along with all of their subclasses.
I believe these three types are meant to be subclassed, so I felt
picking the more general type was correct.
2. There were also a few concrete types (e.g. see socketserver,
subprocess, ftplib...) that I modified to return `None` -- I checked
the source code, and these all seem to return None (and don't appear
to be meant to be subclassable).
3. contextlib.suppress was changed to return bool. I also double-checked
the unittest modules and modified a subset of those contextmanagers,
leaving ones like `_AssertRaisesContext` alone.
* HTTP Handler class annotations for py2/urllib2 & py3/urllib.request
Add full annotations for the following classes:
* Python 2:
* `urllib2.AbstractHTTPHandler`
* `urllib2.HTTPHandler`
* `urllib2.HTTPsHandler`
* Python 3:
* `urllib.request.AbstractHTTPHandler`
* `urllib.request.HTTPHandler`
* `urllib.request.HTTPsHandler`
This information is largely undocumented, and was obtained by directly examining
the Python source code:
* Python 2 (v2.7.15) - https://github.com/python/cpython/blob/v2.7.15/Lib/urllib2.py#L1115-L1243
* Python 3 (v3.7.1) - https://github.com/python/cpython/blob/v3.7.1/Lib/urllib/request.py#L1224-L1364
`urllib2.AbstractHTTPHandler.do_open` takes as a parameter either
`HTTPConnection` or `HTTPSConnection`--one of the classes, not an instance of
either--and constructs an object using only a few of the parameters that either
constructor could use. `HTTPConnectionProtocol` in `stdlib/2/httplib.pyi`
follows a similar patten to `HTTPConnectionProtocol` added to
`stdlib/3/http/client.pyi` in pull request #2582 to describe the type of the
`http_class` that is passed to `do_open`.
It seems that code using HTTPError previously worked by accident
because we used to accept arbitrary keyword arguments when
instantiating BaseException, or any subclass of BaseException
(see https://github.com/python/typeshed/pull/2348).
This commit adds in the correct constructor (which also lets the
user specify the arguments in keyword-argument form).
Note: I'm not very familiar with the urllib libraries, so I opted
to just add the signature and leave it up to somebody else to
fill in the types.
* Add OpenDirector.addheaders and replace type comments with annotations
* Use ClassVar/eliminate `= ...` and add BaseHandler.handler_order (exists in Py2 versions)
This commit reorders any overloads where the first overload was
"shadowing" the second, preventing it from ever being matched by type
checkers that work by selecting the first matching overload alternative.
For example, the first overload alternative below is strictly broader
then the second, preventing it from ever being selected:
class Parent: pass
class Child(Parent): pass
@overload
def foo(x: *int) -> Parent: ...
@overload
def foo(x: int, y: int) -> Child: ...
The correct thing to do is to either delete the second overload or
rearrange them to look like this:
@overload
def foo(x: int, y: int) -> Child: ...
@overload
def foo(x: *int) -> Parent: ...
Rationale: I'm currently [working on a proposal][0] that would amend
PEP 484 to (a) mandate type checkers check overloads in order and
(b) prohibit overloads where an earlier alternative completely shadows
a later one.
[0]: https://github.com/python/typing/issues/253#issuecomment-389262904
This would prohibit overloads that look like the example below, where
the first alternative completely shadows the second.
I figured it would be a good idea to make these changes ahead of time:
if my proposal is accepted, it'd make the transition smoother. If not,
this is hopefully a relatively harmless change.
Note: I think some of these overloads could be simplified (e.g.
`reversed(...)`), but I mostly stuck with rearranging them in case I was
wrong. The only overload I actually changed was `hmac.compare_digest` --
I believe the Python 2 version actually accepts unicode.
Fixes the following issues:
* Literals rather than ... for default values
* None rather than ... for default value of typed variable
* Literals rather than ... # type for top level constants
* # Foo rather than # type: Foo
* return value of init not set to None
* Fix incorrect usage of AnyStr
- sqlite3 was using Union[bytes, AnyStr], which doesn't make sense
- The urllib functions I changed accept either bytes or str for their "safe"
argument
- Also added supports for PathLike to pstats
- Remove some unused imports of AnyStr
* pstats: python 2 accepts unicode
