On Thu, Sep 22, 2016 at 10:29 PM David Mertz <me...@gnosis.cx> wrote:

> On Thu, Sep 22, 2016 at 11:42 AM, Steven D'Aprano <st...@pearwood.info>
> 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.

Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to