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.
We recently cut a new-ish release of typed-ast that [adds a new field][0]
named `kind` to the `ast27.Str` and `ast3.Str` classes. This field
stores whatever string modifiers (like `b` or `u`) were present on the
original string.
As a note, I've confirmed that this field is indeed a str (and not
bytes) for ast27's Str class.
[0]: https://github.com/python/typed_ast/pull/49
This pull request modifies the contribution guidelines to clarify
when and where 'Any' should be used.
In particular, it clarifies that 'Any' is meant mainly to be used as
a "fallback" -- if it's not possible to express a certain type, if we're not
sure what the correct type in some case is, to avoid Union returns, etc...
It also explicitly notes that 'object' should be used over 'Any' when we
want to indicate that some function can accept literally anything.
Typing stubs this way probably won't impact most people, but does make
life a bit easier for people (like me) who want to restrict/forbid the
use of Any as much as possible.
It seems that code using HTTPError previously worked by accident
because we used to accept arbitrary keyword arguments when
instantiating BaseException, or any subclass of BaseException
(see https://github.com/python/typeshed/pull/2348).
This commit adds in the correct constructor (which also lets the
user specify the arguments in keyword-argument form).
Note: I'm not very familiar with the urllib libraries, so I opted
to just add the signature and leave it up to somebody else to
fill in the types.
In short, this change makes sure calls like `map(None, a, b)` behave as
expected when using `--no-strict-optional` is enabled.
For additional context, see https://github.com/python/mypy/issues/5246
Basically, the same thing as [my previous pull request][0], except the
fixes are now focusing on functions with overlapping argument counts.
[0]: https://github.com/python/typeshed/pull/2138
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.
This commit adds a few missing return types to the Python 3 textwrap
stubs and fleshes out the Python 2 textwrap stubs so they're on par with
the Python 3 version.
This change:
1. Changes the order of the arguments in Python 2 and Python 3
to match the order from the source code instead of the
documentation.
2. Adds other undocumented attributes besides whitespace_trans
(for consistency).
3. Moves the '*' argument in TextWrapper.__init__ for Python 3
to match the source code.
4. Made function stub formatting consistent with typeshed style
conventions.
This change modifies the PIPE, STDOUT, and DEVNULL constants in the
subprocess module to be of type 'int'.
Note that the Python 2 subprocess module was already typed this way;
this commit is just updating the Python 3 subprocess module in the same
way.
According to the documentation in the typing module, TypeVars cannot
have only a single constraint. Attempting to do so will actually result
in an exception at runtime. (However, this error is currently ignored
by mypy -- see https://github.com/python/mypy/pull/2626 for a related
pending pull request).
This commit changes all instances of TypeVars using a single constraint
(e.g. `T = TypeVar('T', Foo)`) to use bounds instead (e.g.
`T = TypeVar('T', bound=Foo)`.
This seems to be the correct fix for plistlib after reading the module
docs, but it's less obvious this is correct for unittest. The unittest
module originally had `_FT = TypeVar('_FT', Callable[[Any], Any])` -- an
alternative fix would have been to do `_FT = Callable[[Any], Any]`.
Although I'm not entirely sure what it means to have a bound be a
Callable, I decided to make the assumption that the original authors
probably meant to use TypeVars instead of type aliases for a reason
(possibly to handle classes implementing `__call__`?)
This commit adds some incomplete stubs for the fractions module. In
particular, this commit does not add type signatures for the more
complex functions (such as `__add__`), and just leaves their types as
effectively `Any`.
* Refine stubs for Python 2's decimal module
The decimal module for Python 2 was relatively incomplete, unlike the
decimal module for Python 3. This commit copies the relevant type
signatures from Python 3's decimal module to Python 2's.
There was a lot of code in both stubs and it wasn't clear to me if it
was safe to merge the two modules together, so I refrained from doing
so.
* Allow comparisions with Decimals and Floats
This commit loosens the types for Decimals to allow comparisons like
`Decimal('3.14') < 4.2`. Previously, you could compare decimals with
only other decimals or ints.
* Partially refine numbers.pyi
This commit refines numbers.pyi. More specifically, it...
- Adds in explicit type annotations where it's obvious how to do
so (leaving more non-obvious type signatures alone).
- Adds in missing '@abstractmethod' decorators
- Combines together the Python 2 and Python 3 versions of numbers.pyi.
* Merges Python 2 and Python 3 numbers.pyi
This commit removes the old `stdlib/2.7/numbers.pyi` file and moves the
previously-committed `stdlib/3/numbers.pyi` to the shared `2and3`
directory.
* Modify comment at top of numbers.pyi
Since the stubs are no longer identical to what stubgen creates, the
comment should also probably be changed.
In Python, it's possible to use the `next` builtin method on file
objects produced by `open`. This change modifies `typing.IO` so this
usage will successfully typecheck.
As of Python 2.7, you can pass in multiple iterables into some set
methods like union, intersection, difference, and update. So, for
example, `new_set = a.union(b, c)`.
Michael Lee