-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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
gh-121332: Make AST node constructor check _attributes instead of hardcoding attributes #121334
Conversation
…of hardcoding attributes
"Support for arbitrary keyword arguments is deprecated " | ||
"and will be removed in Python 3.15.", | ||
Py_TYPE(self)->tp_name, key | ||
) < 0) { |
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.
Do you need to actually check later whether there are remaining attributes to be initialized or not? because I would say "ok, they can be left uninitialized if they are already present on the class dictionary" for instance?
For instance ast.Tuple().end_lineno
is None, but ast.Tuple().lineno
raises AttributeError. So maybe we should document the behaviour for AST nodes custom subclasses?
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.
The current behavior is to allow omitting most attributes, though a few default to None. That behavior is somewhat questionable but I'd rather leave it alone for now, at least for 3.13.
Going to merge this soon so it can go into 3.13. |
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.
Getting rid of the hardcoded check LGTM, although I am now mildly curious as to how the hardcoding ever came to be :)
@@ -0,0 +1,3 @@ | |||
Fix constructor of :mod:`ast` nodes with custom ``_attributes``. Previously, |
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.
Previously? Isn't it still raising DeprecationWarning?
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.
It still raises a DeprecationWarning if you pass attributes the class doesn't know about. But now it no longer raises a warning if you set _attributes
on a custom subclass and pass those attributes.
Misc/NEWS.d/next/Library/2024-07-03-07-25-21.gh-issue-121332.Iz6FEq.rst
Outdated
Show resolved
Hide resolved
Thanks @JelleZijlstra for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13. |
Sorry, @JelleZijlstra, I could not cleanly backport this to
|
…nstead of hardcoding attributes (pythonGH-121334) (cherry picked from commit 58e8cf2) Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
GH-121625 is a backport of this pull request to the 3.13 branch. |
…of hardcoding attributes (python#121334)
…of hardcoding attributes (python#121334)
cc @picnixz (thank you for noticing this issue!)
_attributes
for allowed attributes #121332