I made PathLike a protocol in #4447, but it should also be
runtime_checkable.
Caught by mypy_primer:
src/werkzeug/utils.py:646: error: Only @runtime_checkable protocols can be used with instance and class checks
Having an obscure type variable name is causing some pretty inscrutable
errors. For instance:
```
xarray/core/utils.py:466: error: Value of type variable "_LT" of "sorted" cannot be "K"
tornado/simple_httpclient.py:324: error: Value of type variable "_LT" of "min" cannot be "Optional[float]"
```
I think having a more descriptive type variable name here is better for
user experience and helps address the "why" of an error.
Fixes#4288.
- Default imports to THIRD_PARTY, so in effect we merge the FIRST_PARTY and THIRD_PARTY stubs. This means import order is no longer affected by whether typing_extensions is installed locally.
- Treat typing_extensions, _typeshed and some others as standard library modules.
Note that isort master is very different from the latest release; we'll have to do something
different if and when the next isort release comes out.
This is a follow-up on #4232. memoryview, hashlib, and hmac are updated
to use ReadableBuffer type instead of their own home-spun unions of
bytes, bytearray and whatever else each use case used. mmap is being
handled in #4244, and I'll leave BinaryIO for another day (or possibly
another person) because it's going to require some messy code
duplication because the relevant methods are defined in IO[AnyStr].
There's one corner case I'm not quite sure how best to handle: the
documentation for hmac.digest claim that the parmaeters have the same
meanings as in hmac.new, but in CPython the latter has an explicit check
that `key` is bytes or bytearray while the former works with a
memory-view. For now I've matched the documentation.
Also, the documentation for HMAC.update says that `msg` can be any type
supported by hashlib from Python 3.4; but I can't see anything in the
Python 2.7 implementation that would prevent it also taking bytes-like
objects, so I've not tried to treat Python 2 any different to Python 3.
* make io classes inherit from typing IO classes
This makes these classes usable if type annotations are given as "IO"
or "TextIO". In the future, we'll then be able to move open() to
return a concrete class instead (#3951).
* open: introduce concrete return types
Fixes#3951.
We use the values of the "mode" and "buffering" arguments to figure out
the concrete type open() will return at runtime. (Compare the CPython
code in https://github.com/python/cpython/blob/master/Modules/_io/_iomodule.c#L231.)
Technically this is a lie, since we return a heterogeneous iterator, not
a tuple. But since we don't have a way of typing heterogeneous
iterators, this is the best we can do.
Fixes https://github.com/python/mypy/issues/8454
The Python source (Objects/exceptions.c) explicitly checks for null
pointers before using the filename and lineno members. Some libraries,
e.g. pkg_resources, set filename and lineno to undefined values if
indeed none are appropriate.
`int.from_bytes` supports both iterables of ints and objects that define
__bytes__'. As an example `int.from_bytes(iter([1, 0]), 'little'))`
returns 1.
