-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
stubgen: use sys.version_info, rather than hardcoding 3.6 #10907
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
Conversation
Not too familiar with stubgen, so maybe there's a good reason for hardcoding, e.g. to ensure stubs capture sys.version checks in the source? Most stubs in typeshed use sys.version checks for a) checking Python 2, b) if they're stdlib backports. So hopefully this is a reasonable change. Fixes python#10905
I feel like there should be a command-line option to stubgen for this, but using the runtime version is going to be a better experience than just hardcoding 3.6. |
You can already pass a Python executable for stubgen to use, and since stubgen will by default try to import things I feel like it is reasonable to require a Python executable of the version you want present on the system. |
@ethanhs so far |
Right, but if this change is merged then it will use sys.version_info, and so a separate --python-version flag seems unnecessary to me, since you want to be using the version of Python that is importing your code. |
Note that there isn't a way to parse debug f-strings (the concern of all the issue reports) with Python 3.7 at all, i.e., even for mypy proper we require that if you want to check Python 3.x code when x > 7 you need at least Python 3.x |
What will happen if one want to create stub target to py3.6 on a system only have py3.9? |
Yes, but if stubgen is trying to import things from the Python code, it must use the correct Python version anyway, otherwise things are going to be incorrect. |
What are the next steps in getting this merged / released? The solution proposed by @hauntsaninja feels pretty solid. Are there any objections blocking? I feel like the other solution is to use |
I merged it, but releasing is not in my control. |
Not too familiar with stubgen, so maybe there's a good reason for hardcoding, e.g. to ensure stubs capture sys.version checks in the source? Most stubs in typeshed use sys.version checks for a) checking Python 2, b) if they're stdlib backports. So hopefully this is a reasonable change. Fixes python#10905
Not too familiar with stubgen, so maybe there's a good reason for
hardcoding, e.g. to ensure stubs capture sys.version checks in the
source? Even if that's the case, most stubs in typeshed use
sys.version checks for a) checking Python 2, b) if they're stdlib
backports. So hopefully this is a reasonable change.
Fixes #10905, fixes #10791