PEP 484 indicates that all type annotations within a stub file are supposed to be considered forward references even if they are not quoted. This means a type checker needs to use scope-based symbol resolution without regard for code flow order. Lookups will find same-named symbols within the same scope even if they are declared after the type annotation. This change fixes a couple of cases where this occurs and confuses pyright.
Co-authored-by: Eric Traut <erictr@microsoft.com>
This makes mypy think that conditions like
parameter.kind is Parameter.POSITIONAL_OR_KEYWORD
are always false, which triggers `unreachable` warnings, among other
problems.
* Enable some branches for Python2 pathlib2
* Define an alias _PathLike, instead of using multiple branches
* Drop a Python 3.4 branch (the Python 2 branch is identical to
the 3.5+ branch)
* Move Path.__new__ to the top
This doesn't cover everything but it means it a lot of common usages the type will be slightly more useful
Co-authored-by: steve brazier <steve.brazier@trioptima.com>
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.
The following code produces an error in mypy:
import asyncio
from asyncio.subprocess import PIPE
async def main() -> None:
proc = await asyncio.create_subprocess_shell("ls -l", stdout=PIPE)
assert proc.stdout is not None
async for line in proc.stdout:
print(line.decode())
await proc.wait()
asyncio.run(main())
$ mypy --strict file.py
file.py:8: error: "StreamReader" has no attribute "__aiter__" (not async iterable)
This commits fixes this by adding __aiter__/__anext__ methods that are
needed for async iterator protocol.
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.
Since typing doesn't yet have a way to express buffer protocol objects
(python/typing#593), various interfaces have ended up with a mish-mash
of options: some list just bytes (or just bytearray, when writable),
some include mmap, some include memoryview, I think none of them include
array.array even though it's explicitly mentioned as bytes-like, etc. I
ran into problems because RawIOBase.readinto didn't allow for
memoryview.
To allow for some uniformity until the fundamental issue is resolved,
I've introduced _typeshed.ReadableBuffer and _typeshed.WriteableBuffer,
and applied them in stdlib/3/io.pyi as an example. If these get rolled
out in more places, it will mean that we have only one place where they
have to get tweaked in future, or swapped out for a public protocol.
This unfortunately does have the potential to break code that inherits
from RawIOBase/BufferedIOBase and overrides these methods, because the
base method is now more general and so the override now needs to accept
these types as well (which is why I've also updated gzip and lzma).
However, it should be a reasonably easy fix, and will make the
downstream annotations more correct.
A few comments between imports were removed or moved to the top of the
import block, due to behavioral differences between black and isort. See
psf/black#251 for details.
In two instances @overloads at the top of the file needed to be moved
due to psf/black#1490.
