Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Generalize the 'open' plugin for 'pathlib.Path.open' #7643
This pull request adds a plugin to infer a more precise return type for the
This method is actually nearly identical to the builtin
This pull request adds a plugin to infer a more precise return type for the `pathlib.Path.open(...)` method. This method is actually nearly identical to the builtin `open(...)` method, with the only difference being that `pathlib.Path.open(...)` method doesn't have the `file` parameter. So, I refactored the logic in both plugins into a shared helper method.
I guess it's just a somewhat intrusive change, which would require more due diligence. Basically, we'd need to create unions of every possible combination of modes, make sure we properly handle differences between Python 2 and 3 (e.g. the
The number of combinations is also somewhat large (I think ~76 of them in total?), so we'd also maybe want to make sure this doesn't cause a performance regression when handling union subtype checks and such. I think the impact would be negligible since
None of this is really difficult, just mildly time-consuming and tedious, so I went with this quick and simple 5 minute PR.
But if you prefer we avoid investing any more time into the
Yeah, the sheer number of combinations is unfortunate.
I just feel that if we can solve something with a feature of the type system that is better than solving it with a plugin -- a plugin only solves it for mypy, and the plugin API is still poorly documented and evolves more quickly than the type system (and it has no backwards compatibility guarantees).
Another thing is that there are likely quite a few other functions that wrap
If it's too tedious to write the stubs due to some limitation of
and use those in the stubs defining wrappers? (Add whatever other strings are actually supported.)
For what it's worth, so far we use Literal overloads for one file in typeshed: https://github.com/python/typeshed/blob/master/stdlib/3/tempfile.pyi.
msullivan left a comment
I don't have any problem with merging this now, though I agree that it would be better to do it in typeshed.
(Though not if it requires 76 overloads?? I hope that is just the number of elements in the Literals. I needed like 8 overloads for subprocess and found it extremely frustrating.)