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.
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.
Fixes#1997, #2068.
This is tricky because we need to get the return values right (see #1960 for
prior attempts) and we often run into python/mypy#3644. I found that I
could express most signatures correctly using a series of overloads.
A few other changes in here:
- Added splitunc, which according to https://docs.python.org/3/library/os.path.html
should exist in both Unix and Windows.
- Made the second argument to os.path.curdir Optional to match the implementation.
- Fixed os.path.split, whose previous Path-aware signature triggered python/mypy#3644.
* os: merge the top and bottom of os/__init__.pyi
Part of #1427. In preparation for merging the two stubs, I'm making the files
identical as much as possible. This PR merges the top of the file, down to
but not including the definition of statvfs_result, and the bottom up to
and including os.utime.
This PR mostly adds more "if sys.version_info" block. Until the merger
completes, we'll have some Python 2 blocks in the Python 3 stub and vice versa.
I also add a few missing constants and arguments.
In followup PRs I'll merge the rest of the file. I'll put the trickiest part
(the return values of functions like os.stat) in its own PR.
* back out DirEntry from py2
It relies on stat_result which we don't have yet in py2.
In Python 2, doing
os.path.join(u"foo", "bar")
is actually legal, and returns a unicode string.
Also os.path.relpath always returns the type of its first argument.
(The solution is not perfect -- e.g.
os.path.join("a", "b", "c", "d", u"e")
will still result in a type error. )
