* typing: fix argument names of cast
* typing: use private _Alias class
For py37 and above, this is _GenericAlias, for py36 and below it's
_TypeAlias. I don't think we need to make typing.pyi definitions
correspond more precisely, but we should avoid leaking a
typing.TypeAlias class
While these implementations don't matter for the 'typing' module
itself, these are also imported to serve as the implementations
for the 'collection.abc' module.
Fixes#3029
* Add os.add_dll_directory()
* Add memfd_create() and flags
* Add type annotation to flags
* Add stat_result.st_reparse_tag and flags
* Add ncurses_version
* Add Path.link_to()
* Add Picker.reducer_override()
* Add plistlib.UID
* Add has_dualstack_ipv6() and create_server()
* Add shlex.join()
* Add SSL methods and fields
* Add Python 3.8 statistics functions and classes
* Remove obsolete sys.subversion
* Add sys.unraisablehook
* Add threading.excepthook
* Add get_native_id() and Thread.native_id
* Add Python 3.8 tkinter methods
* Add CLOCK_UPTIME_RAW
* Add SupportsIndex
* Add typing.get_origin() and get_args()
* Add unicodedata.is_normalized
* Add unittest.mock.AsyncMock
Currently this is just an alias for Any like Mock and MagicMock. All of
these classes should probably be sub-classing Any and add their own
methods. See also #3224.
* Add unittest cleanup methods
* Add IsolatedAsyncioTestCase
* Add ElementTree.canonicalize() and C14NWriterTarget
* cProfile.Profile can be used as a context manager
* Add asyncio task name handling
* mmap.flush() now always returns None
* Add posonlyargcount to CodeType
This was discussed in #3181 and the correct explanation was given that
object ought to be preferred here. In practice this caused an obscure
issue with mypy when using this operations on the results of
six.viewkeys(), since it decided that it wanted a mapping *from* object
as a result of inference contexts. Grumble.
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.
Both are None if there were no groups matched. Also 'lastgroup'
will be None if the matched group was nameless.
The Python 2 versions of these annotations already used Optional.
This includes two things to sync up with recent runtime updates:
* Move `Final`, `@final`, `Literal`, and `TypedDict` to `typing` (`typing_extensions` still defines or re-exports them)
* Rename `@typing.runtime` to `@typing.runtime_checkable`, while keeping `@runtime` as a backwards-compatible alias in `typing_extensions`.
According to Ivan, PEP 544 intentionally did not specify whether method conformance check in protocol inference should look at parameter names. For example, it's up to the type checker to decide whether a class with method defined as `def foo(self, x: int)` would implement a protocol with method `def foo(self, y: int)`.
Mypy decided to ignore parameter names altogether, but we Pyre team decided to be more strict and refuse to match different parameter names (as it is unsound to do so when those methods are invoked with named parameters). Since we rely on the typeshed stubs, we want to make sure at least the important stubs on typeshed conform to our standard.
This PR changes `Container.__contains__` to use dunder (i.e. positional-only) parameter name specified in PEP484. This change should not affect mypy since it ignores parameter names, but will make Pyre happy as it eliminate the naming requirement for all classes that want to conform to the `Container` protocol.
In python 3, add an overload for there being no digits argument
and make it return int.
In python 2, __round__ doesn't exist and SupportsRound doesn't exist
in the typing module. Use SupportsFloat for python 2 round().
Remove decimal's __round__ overload that takes None, since it doesn't exist
Fixes#1940.
This makes it so that mypy will infer the common base class of these
classes to be Awaitable instead of Iterable. I verified that this
fixes the errors in the script posted by @neilconway.
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.
Ivan Levkivskyi