Skip to content

Flexible module availability checks #596

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

Closed
srittau opened this issue Dec 4, 2018 · 3 comments
Closed

Flexible module availability checks #596

srittau opened this issue Dec 4, 2018 · 3 comments
Labels
topic: feature Discussions about new features for Python's type annotations

Comments

@srittau
Copy link
Collaborator

srittau commented Dec 4, 2018

Currently to mark a package or module to be available in a certain Python version, it has to be moved to a specially named directory (e.g. stdlib/3.4). This has a few shortcomings:

  • Module removals can't be expressed (like macpath in 3.8)
  • Additions of submodules is awkward and usually has to duplicate multiple files
  • Platform-availability can't be expressed

I suggest to add a marker inside stub files based on the existing sys.version_info/sys.platform checks to mark the unavailability of a module, in addition to the existing path-based system. This could, for example, look like this:

if sys.version_info >= (3, 8):
    raise NotImplementedError()
if sys.platform != "win32":
    raise NotImplementedError()

This might prove hard to implement "correctly", i.e. refuse imports of unavailable modules, but an easy workaround is to print a warning when such a construct is encountered while parsing a file and possibly stop parsing the stub at this point.

@JelleZijlstra
Copy link
Member

Mypy landed a similar feature recently (python/mypy#5894).

@srittau
Copy link
Collaborator Author

srittau commented Dec 4, 2018

Huh, Guido must be psychic. This basically fulfills the use case above, except it can't determine that a module can't be imported at all. But in practice this should not matter. This seems like a feature that would be a good fit for the type stub PEP.

@srittau
Copy link
Collaborator Author

srittau commented Nov 4, 2021

This is mostly moot due to the new typeshed layout, where the VERSIONS file specifies available versions. Only open issue are modules unavailable in some OSes, but that sounds more of a typeshed issue anyway.

@srittau srittau closed this as completed Nov 4, 2021
@srittau srittau added the topic: feature Discussions about new features for Python's type annotations label Nov 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: feature Discussions about new features for Python's type annotations
Projects
None yet
Development

No branches or pull requests

2 participants