Skip to content

[Regression] TypeVar crashes when name is specified via keyword parameters #110782

Closed

Description

@mxschmitt

Crash report

What happened?

from typing import TypeVar
TypeVar(name="Handler")

Good: 3.11.X
Bad: 3.12.0

Downstream issue: jfhbrook/pyee#134

CPython versions tested on:

3.12

Operating systems tested on:

Linux, macOS

Output from running 'python -VV' on the command line:

Python 3.12.0 (main, Oct 12 2023, 00:42:11) [GCC 12.2.0]

Linked PRs

Activity

  1. added
    type-crashA hard crash of the interpreter, possibly with a core dump
    on Oct 12, 2023
  2. mxschmitt commented on Oct 12, 2023

    @mxschmitt
    ContributorAuthor

    Investigation: Changing TypeVar(name="Handler") to TypeVar("Handler") fixes it for me.

  3. JelleZijlstra commented on Oct 12, 2023

    @JelleZijlstra
    Member

    This is possibly a bug in Argument Clinic (see

    typevar.__new__ as typevar_new
    ): if name is passed as a positional argument and there are no constraints, constraints is an empty tuple, but if it's a keyword argument, constraints is NULL.

    I'll send a PR in a moment with a workaround in typevarobject.c.

  4. added 2 commits that reference this issue on Oct 12, 2023
  5. added a commit that references this issue on Oct 12, 2023
  6. JelleZijlstra commented on Oct 12, 2023

    @JelleZijlstra
    Member

    Fix is merged, and will be in 3.12 soon; 3.12.1 should include the fix.

    I'll note that using a keyword argument for the name of a TypeVar is not an officially supported part of the type system, so to make your code portable across type checkers and Python versions, you should use a positional argument for the name. It appears that pyright supports the keyword argument form, but mypy does not. We'll continue to support the keyword argument form at runtime for backwards compatibility.

  7. added a commit that references this issue on Oct 12, 2023
  8. sobolevn commented on Oct 14, 2023

    @sobolevn
    Member

    Thanks!

    @JelleZijlstra would you accept

    *constraints: object
    *

    to be changed to just

    *constraints
    

    ?

    Because this seems like a fortunate event that this notation works. I was not able to find that this is a documented approach.

    If so, I would send a PR :)

  9. AlexWaygood commented on Oct 14, 2023

    @AlexWaygood
    Member

    Because this seems like a fortunate event that this notation works. I was not able to find that this is a documented approach.

    We should try to make sure AC raises an error if it encounters syntax like this which isn't supported! Cc. @erlend-aasland

  10. sobolevn commented on Oct 14, 2023

    @sobolevn
    Member

    Ok, will do after #110864

  11. JelleZijlstra commented on Oct 14, 2023

    @JelleZijlstra
    Member

    Thanks @sobolevn for investigating further!

    I'm fine with whatever syntax works here, but ideally AC should support annotations on *args (e.g., I should be able to write *args: bool to get any number of bool args), and as Alex says it should error on unsupported constructs.

  12. added a commit that references this issue on Sep 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

topic-typingtype-crashA hard crash of the interpreter, possibly with a core dump

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions