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

Class-qualified annotation expressions #1884

Open
samwgoldman opened this issue Nov 9, 2024 · 2 comments
Open

Class-qualified annotation expressions #1884

samwgoldman opened this issue Nov 9, 2024 · 2 comments
Labels
topic: documentation Documentation-related issues and PRs

Comments

@samwgoldman
Copy link

The wonderfully useful specification of type annotation expressions describes what kinds of expressions are valid type annotations.

I believe the spec does not include a case which type checkers support, although as we will see this comes down to semantics :)

class A:
    class B:
        pass

x: A.B = A.B()

The A.B annotation seems to fall under the name rule:

| name
      (where name must refer to a valid in-scope class,
       type alias, or TypeVar)

The spec helpfully continues:

Any leaf denoted as name may also be a qualified name (i.e., module '.' name or package '.' module '.' name, with any level of nesting).

The concept of a "qualified name" occurs only in this section, and the parenthetical explanation serves as it's most precise definition, as far as I can tell.

Should we extend the definition of "qualified name" to also include class members? Or maybe I should read the class as a "module" or a "package" and the existing definition suffices?

@samwgoldman samwgoldman added the topic: documentation Documentation-related issues and PRs label Nov 9, 2024
@erictraut
Copy link
Collaborator

Should we extend the definition of "qualified name" to also include class members?

Yes, I think that would be a good clarification. This section focuses primarily on the syntactic rules for type expressions and intentionally omits some of the detailed semantic rules because they are covered in more detail elsewhere in the spec. That said, I agree that there's room for additional clarity in the notes section here.

@JelleZijlstra
Copy link
Member

Yes, this is a good point; I overlooked this possibility when I wrote that text.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: documentation Documentation-related issues and PRs
Projects
None yet
Development

No branches or pull requests

3 participants