Skip to content

PEP 695: Rename typeparams to type_params in AST #104656

Description

@JelleZijlstra

PEP-695 introduces a few new AST attributes that are currently called typeparams, as specified in https://peps.python.org/pep-0695/#ast-changes. However, @AlexWaygood rightly points out (#104642 (comment)) that type_params would be more readable and in line with most of the rest of the AST. Should we change it?

cc @erictraut for this PEP, @cdce8p who made some AST changes in this area before, @pablogsal @isidentical as AST experts.

Linked PRs

Activity

  1. AlexWaygood commented on May 19, 2023

    @AlexWaygood
    Member

    Reposting my comment in #104642 (comment) here, for visibility:

    Nearly all other attributes on AST nodes in Python use snake_case -- type_ignores, decorator_list, end_lineno, type_comment, end_col_offset, format_spec, is_async, kw_defaults, context_expr, optional_vars, kwd_attrs, kwd_patterns. And the attribute on TypeAliases, functions and classes at runtime is __type_params__, not __typeparams__.

    There's a few examples of smushedtogethercase attributes on AST nodes -- finalybody, kwonlyargs, vararg, asname. But they're definitely in the minority.

    I would greatly prefer it if this attribute was renamed to be type_params.

  2. JelleZijlstra commented on May 19, 2023

    @JelleZijlstra
    MemberAuthor

    The same goes for the typeparam type in the AST. Naming it type_param would be consistent with e.g. type_ignore.

    I'm working on a draft PR.

  3. added a commit that references this issue on May 19, 2023
  4. cdce8p commented on May 21, 2023

    @cdce8p
    Contributor

    From a users perspective either works fine. It would be more important to not change it unnecessarily after it has been released. I.e. I wouldn't recommend to go back and "fix" finalybody, kwonlyargs, etc.

  5. AlexWaygood commented on May 21, 2023

    @AlexWaygood
    Member

    @erictraut, I think we'd be especially interested in your thoughts on this as the author of the PEP, since typeparams is clearly specified by the PEP as the name for these nodes. Would you object to this change?

  6. erictraut commented on May 21, 2023

    @erictraut
    Contributor

    I don't have a strong opinion one way or the other on the AST names. I tried to follow the patterns I could see when I implemented my prototype. If there are some other conventions or precedents that I missed, I have no objections to changing these names.

  7. gpshead commented on May 21, 2023

    @gpshead
    Member

    I'm in favor of including the _ becauserunonwords_are_less_readable.

  8. JelleZijlstra commented on May 21, 2023

    @JelleZijlstra
    MemberAuthor

    Unless someone disagrees strongly I'll merge the change to type_params tonight, in time for the beta tomorrow.

  9. added a commit that references this issue on May 22, 2023
  10. JelleZijlstra commented on May 22, 2023

    @JelleZijlstra
    MemberAuthor

    Wewilluseunderscores.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions