Skip to content
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

Open issue: introspection: module name, sane defaults #15

Open
Viicos opened this issue Feb 18, 2025 · 1 comment
Open

Open issue: introspection: module name, sane defaults #15

Viicos opened this issue Feb 18, 2025 · 1 comment
Labels
open issues Open issues to be discussed with other users of the runtime typing ecosystem

Comments

@Viicos
Copy link
Member

Viicos commented Feb 18, 2025

The introspection is meant to be provide high-level utilities to inspect annotations at runtime.

  • The current module name could be changed. Any ideas?

  • There are two functions — get_literal_values() and inspect_annotation() — that can unpack PEP 695 type aliases. When such type aliases are encountered, you generally don't need to unpack them eagerly. For instance, with the following:

    type MyInt = Annotated[int, Gt(1)]
    
    @my_dataclass
    class MyClass:
        m: list[MyInt]

    You can retrieve the value of the MyInt alias only when processing the class argument of list.
    However, there are cases where having type aliases eagerly unpacked is beneficial. For instance:

    type MyInt = Annotated[int, field(alias='test')]
    
    @my_dataclass
    class MyClass:
        m: Myint

    The @my_dataclass implementation could benefit from having MyInt eagerly unpacked, so that it can detect the field alias early in the class creation (in Pydantic, this happens in the first class creation step, fields collection. We then have a step to generate the type validation logic, and realizing that the annotated metadata contains field metadata such as aliases isn't ideal).

    For this reason, the default value for unpack_type_aliases is to unpack them eagerly. However, this makes the functions unsafe as NameErrors can happen. Probably we should switch to skip as a default value, but recommend using eager.

@Viicos Viicos added the open issues Open issues to be discussed with other users of the runtime typing ecosystem label Feb 18, 2025
@Viicos
Copy link
Member Author

Viicos commented Feb 21, 2025

  • The @my_dataclass implementation could benefit from having MyInt eagerly unpacked, so that it can detect the field alias early in the class creation (in Pydantic, this happens in the first class creation step, fields collection. We then have a step to generate the type validation logic, and realizing that the annotated metadata contains field metadata such as aliases isn't ideal).

Turns out we changed this recently. A better default for inspect_annotation() would be to skip unpacking type aliases. The current get_literal_values() default will be kept however.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
open issues Open issues to be discussed with other users of the runtime typing ecosystem
Projects
None yet
Development

No branches or pull requests

1 participant