Skip to content

Improve the constructors of AST nodes #105858

Description

@JelleZijlstra

Currently, the constructors for AST nodes accept arbitrary keyword arguments and don't enforce any value:

>>> node=ast.FunctionDef(what="is this")
>>> node.what
'is this'
>>> node.name
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'FunctionDef' object has no attribute 'name'

Problems with the current situation:

  • To make a correct AST node, you have to pass every attribute, including ones that could sensibly default to an empty list
  • You cannot rely on attributes like name being present
  • It's possible to create useless, broken AST nodes like the above
  • Introspection tools can't easily tell what the signature of the constructor is supposed to be
  • Adding new fields to an AST node causes various compatibility issues (PEP-695: Potentially breaking changes made to __match_args__ attributes of AST nodes #104799)

Proposed solution for 3.13:

  • Default all fields to some sensible value if they are not provided to the constructor: an empty list for list fields, and None for other fields.
  • Emit a DeprecationWarning if the constructor is passed arguments that it doesn't recognize (e.g., what above). In 3.15, this will raise an error.
  • Add a __text_signature__ to the AST classes indicating the expected signature.

Linked PRs

Activity

  1. furkanonder commented on Jun 16, 2023

    @furkanonder
    Contributor
  2. added a commit that references this issue on Jun 17, 2023
  3. brandtbucher commented on Jun 20, 2023

    @brandtbucher
    Member

    Yes please! This has been such a pain point for me.

    One note: we should probably only default optional fields (?) to None, and require everything else.

  4. JelleZijlstra commented on Jun 20, 2023

    @JelleZijlstra
    MemberAuthor

    One note: we should probably only default optional fields (?) to None, and require everything else.

    Agree, I ended up doing that in my draft PR. Omitting a required field (e.g. FunctionDef.name) will raise a DeprecationWarning, as will passing a bogus field.

  5. added
    stdlibStandard Library Python modules in the Lib/ directory
    on Nov 27, 2023
  6. added a commit that references this issue on Feb 28, 2024
  7. JelleZijlstra commented on Feb 28, 2024

    @JelleZijlstra
    MemberAuthor

    Merged!

  8. added a commit that references this issue on Feb 28, 2024
  9. JelleZijlstra commented on Feb 28, 2024

    @JelleZijlstra
    MemberAuthor

    Reopening as I broke all the buildbots

  10. added a commit that references this issue on Feb 28, 2024
  11. added a commit that references this issue on Feb 28, 2024
  12. added a commit that references this issue on Feb 28, 2024
  13. added 2 commits that reference this issue on Mar 4, 2024
  14. added 2 commits that reference this issue on Mar 25, 2024
  15. hroncok commented on Mar 26, 2024

    @hroncok
    Contributor

    There might be a regression: #117266

  16. added 2 commits that reference this issue on Apr 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    stdlibStandard Library Python modules in the Lib/ directorytopic-parsertype-featureA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions