-
-
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
How much do we care about positional-only args? #3693
Comments
I would prefer to just go with the latest version in cases like this, since there is fairly little risk of actual code attempting to use these arguments as keyword arguments, and as you say it would complicate the stubs. I'm interested to hear other opinions though. As for your other questions:
|
As an addendum to what Jelle wrote: I wouldn't want to reduce accuracy for positional-only arguments, i.e. if something already has branches, I wouldn't want to accept a patch that removes those. But PR that changes the args from one kind to the other, because it has changed in later Python versions, is fine. |
Sounds good, thanks both! |
It's fairly common for arguments that were positional-only to become no longer positional-only between minor versions of Python. For example, zipimport between 3.7 and 3.8:
We can branch on
sys.version_info
to capture this — and I'm happy to do that — but figured I'd check whether this is actually desired or not before doing something that's pretty nitpicky. The upside here is accuracy, the downside here is it makes the stubs less readable and it can mask more important differences between Pythons.An alternative would be to only aim for positional-only arg accuracy in the latest Python release (with anything else being discretionary). One way this would manifest is if we introduced
stubtest
to typeshed CI, we could run against older versions of Python with--ignore-positional-only
.While I'm here, some other questions:
Mapping.get
?The text was updated successfully, but these errors were encountered: