New addition: typing.CustomType

Ideas
21

I strongly oppose to the name Self as being a new type in typing for Python 3.11+. I strongly suggest the name of the type being Instance.

It would be more evident what is going on if an Instance type is used to annotate the reference self.

self is a reference to an instance of a class, so the annotation in that case would be more obvious if it were self: Instance, not self: Self.

What do you find more obvious?

This

from typing import Self

class MyClass:
    def create_copy(self: Self) -> Self:
        return self

or this

from typing import Instance

class MyClass:
    def create_copy(self: Instance) -> Instance:
        return self

?

1 Like
22

I find Instance very confusing. The type of self is an instance? Does not make sense; also a type annotation is a class, so what does it meant that the class is instance?!

The annotation with Self does not have this issue; I would interpret it as: maybe itā€™s a way to refer to MyClass before itā€™s done being defined, or maybe itā€™s a reference to the actual class or subclass at runtime, like cls in a class method. I would check the docs to know.

23

I find the self: Self thing very confusing. Itā€™s more evident with self: Instance. Maybe thatā€™s just me.

1 Like
24

I would say that others agree that self: Self is ugly, but why do you think you need to put self: Self as an annotation? The draft PEP doesnā€™t say that and in fact explicitly says the opposite, that annotating self is uncommon. You would not write self: Self as others said earlier in this thread.

Also as an example of this in the real world, Rust already has this in its type system. The method syntax is similar to Pythonā€™s with self being the first parameter of a method. Rust is also strongly typed and requires type annotations on all arguments to a method except self because it would be redundant.

25

Ah, interesting. Well, the self reference of a subclass needs an annotation. Currently, this is done by using the TypeVar, but I find this TypeVar thing very ugly.

Look at this ugliness:

from typing import TypeVar
MyBaseClassT = TypeVar("MyBaseClassT", bound="MyBaseClass")

class MyBaseClass:
    ...

class MySubClass(MyBaseClass):
    def create_copy(self: MyBaseClassT) -> MyBaseClassT:
        return self

But by having this new Self type, we wonā€™t need this ugly TypeVar hack anymore. So like this:

from typing import Self

class MyBaseClass:
    ...

class MySubClass(MyBaseClass):
    def create_copy(self: Self) -> Self:
        return self

Base (parent) classes never annotate self, but all subclasses need to annotate self. The idea of this PEP 673 (adding a new Self type to the typing module) is to provide a better approach (better than using the TypeVar hack) to annotate the self reference of a subclass.

When postponed evaluation of annotations gets incorporated into Python (currently, we use the from __future__ import annotations hack), I hope that we will be able to annotate the self reference of a subclass by just typing out the name of its base class, hence not needing the Self type at all. Would be nice, though.

26

This is incorrect usage most of the time - you should always write classes to support subclassing if possible, so you should almost never return ā€œClassNameā€, but Self instead. For the same reason you should refer to the current class as self.__class__ or type(self), and use class methods and cls. You can use a looser type (like the base class) on assignment, but not for the return type.

Whatā€™s the status of PEP 673? Iā€™d love to see it in, Iā€™m really happy to see Self in typing_extensions, but I donā€™t want it to disappear on me. The TypeVar is really a pain, especially when you have multiple classes in one file. Plus this encourages good class design. I couldnā€™t find a discussion on it.

27

@henryiii it was submitted for Steering Council consideration just yesterday! Submission for SC consideration: PEP 673 -- Self Type Ā· Issue #95 Ā· python/steering-council Ā· GitHub

2 Likes
28

I have now embraced the fact that the new Self type might be useful. It sure as hell is a better alternative to the TypeVar hack.

Now I have a question. Is the TypeVar thing going to be removed from the language if the Self type is accepted for Python 3.11 by the Steering Council?

29

Definitely not, TypeVar is critically important for lots of other situations that Self canā€™t replace - generic types for example.

2 Likes