Skip to content

Conversation

@davidhalter
Copy link
Contributor

I have tried to create a first draft for disallowing access to variables through the class object containing Self, as discussed here.

The general reception of this proposed change was pretty positive, but I guess we are all not sure how this rule should be worded.

The by far biggest issue is that I write:

Accessing a variable through the class object that has a type annotation where
the annotation contains an occurrence of Self is not allowed, because Self can
be different depending on the class in the inheritance hierarchy:

where "contains an occurrence of Self" is according to Eric a bit of a new concept. I guess I understand that this is not well defined in the glossary or anywhere else and can of course be used for other things as well. I have tried to skim the Spec and found the following usages in the spec:

  • glossary.rst: A type is "fully static" if it does not contain any gradual form.
  • glossary.rst: All types in the Python type system are "gradual". A gradual type may be a fully static type, or it may be Any, or a type that contains Any or another gradual form.
  • generics.rst: We reject type aliases containing Self. Supporting Self

There's also two times where "in" is used:

  • generics.rst: Note that we reject Self in staticmethods. Self does not add much
  • generics.rst: Likewise, we reject Self in metaclasses. Self consistently refers to the

I have not found other language about this. I have tried to search for "depends on", "references", "mentions", "introduces" and none of them are used.

However I feel like this concept is often talked in almost implicit ways about TypeVars/Self. For example in the chapter "Type Parameters as Parameters to Generics" (talks about T1 = TypeVar("T2", default=list[T1])):

Type parameters are valid as parameters to generics inside of a default

I feel like there's a couple of other places where different words are used, but it's not like this concept is new.

Please let me know what you all think. I'm happy to improve the wording.

@davidhalter davidhalter force-pushed the disallow-self-class-access branch from 26f68f4 to 88422ea Compare January 8, 2026 22:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant