On Thu, Sep 22, 2016 at 10:29 PM David Mertz
On Thu, Sep 22, 2016 at 11:42 AM, Steven D'Aprano
wrote: This makes it necessary to use string representation for names that are not yet bound, which affects almost every class definition.
Almost every class? Really? I find that implausible. Still, I can see it affecting *many* class definitions, so let's not quibble.
I would say this affects a "rare class here and there." Almost all typing will be with things defined in the `typing` module (or built-ins). I guess once in a while we'll see e.g. `Sequence[CustomThing]`, but it will be uncommon for that typing involving `CutomThing` to be within CustomThing itself (well, unless you use much more recursion than Python encourages).
I think we're talking about different things here. I just referred to the common need to use the name of the current class in type annotation class A: def add(self, other: A) -> A: ...
-1 on complicating the simple Python model that expressions are evaluated when they are reached.
I think there is a decent argument for a more general concept of macros, or symbols, or simpler delayed evaluation than lambda for Python in general. I see places where this would be very nice for Pandas, for example, and for Dask (I work with the developers of both of those projects).
In such a hypothetical future world we might come to allow, e.g. `Sequence[#CustomThing]` where some general lazy facility or indirection is indicated by the '#' (just a placeholder for this comment, not a proposal). But if that comes about, it should be available everywhere, not only in annotations.
I generally agree, but this future world must be very far and has many consequences, whereas the story of annotations is special in that it's not actually an expression, to the reader. Elazar