CDLL.__getattr__ and __getitem__ return function pointers that have a __name__ attribute set, so "CDLL(lib).fun.__name__" is valid code but currently not covered.
* PEP 484 says that type checkers should assume that all types used in a stub should use forward declarations even though they are not quoted. This stub is using the symbol "type" within the context of a class scope. The "type" symbol is declared within this scope, so pyright assumes that the forward declaration should be used. The solution is to define a symbol with a different name in the outer scope to avoid the name conflict.
* Fixed import sort order.
Co-authored-by: Eric Traut <erictr@microsoft.com>
* Pyright detects and reports cases where a multi-part module name is accessed but is not explicitly imported. These are dangerous because they rely on import resolution ordering within a program, which can easily change. This change eliminates errors detected by pyright.
* Fixed regression caught by CI test.
* Fixed black formatting issues.
Co-authored-by: Eric Traut <erictr@microsoft.com>
Add support for the following syslog facilities:
- LOG_NTP
- LOG_SECURITY
- LOG_CONSOLE
- LOG_SOLCRON
In addition, reorder the entries to match the CPython implementation to
make it easier to read.
typing.Mapping is not a protocol, which has caused problems in the past.
(E.g. python/typeshed#3569, see also python/typeshed#3576.) This
introduces a few narrow protocols to _typeshed.pyi that can be used in
place of Mapping.
Not all uses of Mapping can be replaced. For example, cgi.FieldStorage
explictly checks whether the supplied headers argument is a Mapping
instance.
According to the official docs, "user can be a system user name or a uid;
the same applies to group".
Co-authored-by: Artem Simonov <artem.simonov@dejero.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.
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.
* Update mmap stubs for newer Python versions
Based on the Python stdlib documentation:
- Since Python 3.5, mmap.{find,rfind,write} all accept any bytes-like.
I've used the _typeshed.ReadableBuffer alias defined in #4232.
- Since Python 3.6, mmap.write returns the number of bytes written.
- Since Python 3.3, mmap.read allows None as the parameter; while in
Python 2 the argument cannot be omitted.
* Further clean up mmap.pyi
Use the fact that Python 3.0-3.4 are no longer supported to clean up the
version-dependent logic. Functions that always have different signatures
in Python 2/3 are moved from the base _mmap[bytes] to the mmap subclass.
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.
