-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Potentially merge Python 2 and 3 stubs for many modules #4
Comments
Here is what we found useful in PyCharm (written using our old syntax):
|
Sharing code between pyi files sounds even more useful for https://github.com/JukkaL/typeshed/issues/3 However, concerning type aliases, I'm not sure how often we'll see the case that the Python 2 and the Python 3 version off the stub are exactly the same, except one uses unicode and the other uses str. |
Once mypy (and other systems) support version checks as described in PEP 484 (https://www.python.org/dev/peps/pep-0484/#version-and-platform-checking) we should be able to unify many more stubs. |
Have master branch up-to-date
Here is a list of modules that a simple diff between stdlib/2 and stdlib/3 uncovered (please edit as appropriate):
The packages (marked in italics) need special consideration, since they might contain submodules that don't exist in both versions. |
Also json, where the stub is currently a module in stdlib/2, but a package in stdlib/3. In the standard library it is a package in both. |
Can we close this? In 2020, it seems like it could be unnecessary burden (and potentially cause errors in py2 stubs by py3-minded people) to merge py2 and py3 stubs using version checks. It's a different matter if the files are identical, but a quick command makes it seem like that's not really the case, see details. Files which have the same content hash, compare to what's enforced by check_consistent.py
|
I agree, this hardly seems worth it any more. Hopefully in the not-too-distant future we can drop support for Python 2 completely. |
Okay, sounds good! Closing this and the similar #1427 |
We'd need to add aliases for string-like types such as str/bytes/unicode, and these would be different between Python 2 and 3. We'd need to decide where to define the type aliases, either in the stub of the module that uses them or in a shared typeshed-related (?) module that is only available as a stub.
The text was updated successfully, but these errors were encountered: