-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
gh-115881: Document feature_version limitations #115980
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great to me!
@@ -2180,12 +2180,13 @@ and classes for traversing abstract syntax trees: | |||
modified to correspond to :pep:`484` "signature type comments", | |||
e.g. ``(str, int) -> List[str]``. | |||
|
|||
Also, setting ``feature_version`` to a tuple ``(major, minor)`` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest adding maybe a modal box to highlight this a bit more?
``await`` as variable names. The lowest supported version is | ||
``(3, 7)``; the highest is ``sys.version_info[0:2]``. | ||
Setting ``feature_version`` to a tuple ``(major, minor)`` will result in | ||
a "best-effort" attempt to parse using that Python version's grammar. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe also explicitly state that it's not guaranteed to disallow all constructs that weren't possible in a specific version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would even mention some of them:
with
(current issue)- relaxed grammar for decorators
- maybe something else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pushed a commit that expands what "best-effort" means, lysnikolaou let me know if that improves the explicitness!
I think I'd prefer not to get into details. I don't want users to expect that we list all divergences in behaviour here, nor do I think listing all divergences would be particularly useful for current users of feature_version
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Thanks @hauntsaninja for the PR, and @pablogsal for merging it 🌮🎉.. I'm working now to backport this PR to: 3.11, 3.12. |
Sorry, @hauntsaninja and @pablogsal, I could not cleanly backport this to
|
Sorry, @hauntsaninja and @pablogsal, I could not cleanly backport this to
|
GH-116173 is a backport of this pull request to the 3.12 branch. |
GH-116174 is a backport of this pull request to the 3.11 branch. |
ast.parse()
believes valid context manager py38 syntax to be invalid whenfeature_version=(3, 8)
is passed #115881📚 Documentation preview 📚: https://cpython-previews--115980.org.readthedocs.build/