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.
