Hi all,
Annotations of function parameters and variables are evaluated when
encountered. This makes it necessary to use string representation for names
that are not yet bound, which affects almost every class definition. It is
also easy to forget, and the result might be a (very uninteresting)
exc
On Thu, Sep 22, 2016 at 1:19 PM, אלעזר wrote:
> I propose delaying evaluation of annotation-expressions by either keeping
> the AST of the annotation, or turning it implicitly from EXP into "lambda:
> EXP". Inspection code that is interested in this information can access it
> be calling (or eval
On Thu, Sep 22, 2016 at 05:19:12PM +, אלעזר wrote:
> Hi all,
>
> Annotations of function parameters and variables are evaluated when
> encountered.
Right, like all other Python expressions in general, and specifically
like function parameter default arguments.
> This makes it necessary to
On Thu, Sep 22, 2016 at 9:43 PM Steven D'Aprano wrote:
> On Thu, Sep 22, 2016 at 05:19:12PM +, אלעזר wrote:
> > Hi all,
> >
> > Annotations of function parameters and variables are evaluated when
> > encountered.
>
> Right, like all other Python expressions in general, and specifically
> like
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* clas
On Thu, Sep 22, 2016 at 10:29 PM David Mertz wrote:
> 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 fin
On Thu, Sep 22, 2016 at 12:35 PM, אלעזר wrote:
> 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 abo
On Thu, Sep 22, 2016 at 12:35 PM, אלעזר wrote:
> 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: ...
>
Yeah, I find the need for using the string "A" h
On Thu, Sep 22, 2016 at 10:45 PM David Mertz wrote:
> On Thu, Sep 22, 2016 at 12:35 PM, אלעזר wrote:
>
>> 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
On Thu, Sep 22, 2016 at 10:58 PM David Mertz wrote:
> On Thu, Sep 22, 2016 at 12:35 PM, אלעזר wrote:
>
>> 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)
On Thu, Sep 22, 2016 at 12:59 PM, אלעזר wrote:
> I don't If this feature is "nice, but does not worth the complication",
>> then so be it; I can't claim I know better. I only speculate that it does
>> not necessarily requires a new custom type.
>>
>
I don't mean a runtime type here (necessarily),
On Thu, Sep 22, 2016 at 3:58 PM, David Mertz wrote:
> It's more verbose, but you can also spell it now as:
>
> class A:
> def __add__(self, other: type(self)) -> type(self): ...
>
No, you can't:
>>> class A:
... def __add__(self, other: type(self)) -> type(self): ...
...
Traceback (most
On Thu, Sep 22, 2016 at 11:02 PM David Mertz wrote:
> On Thu, Sep 22, 2016 at 12:59 PM, אלעזר wrote:
>
>> I don't If this feature is "nice, but does not worth the complication",
>>> then so be it; I can't claim I know better. I only speculate that it does
>>> not necessarily requires a new custo
Doh!
Yes, of course 'self' is only a scoped name within the body of the method,
not in the signature.
On Thu, Sep 22, 2016 at 1:02 PM, Alexander Belopolsky <
[email protected]> wrote:
>
> On Thu, Sep 22, 2016 at 3:58 PM, David Mertz wrote:
>
>> It's more verbose, but you can also s
On Thu, Sep 22, 2016 at 11:02 PM David Mertz wrote:
> On Thu, Sep 22, 2016 at 12:59 PM, אלעזר wrote:
>
>> I don't If this feature is "nice, but does not worth the complication",
>>> then so be it; I can't claim I know better. I only speculate that it does
>>> not necessarily requires a new custo
On Thu, Sep 22, 2016 at 4:29 PM, אלעזר wrote:
> Just as a demonstration, the parser can transform `EXP` into `lambda: EXP`
> - and that's it. It will not solve everything (e.g. error messages and
> .__annotation__ access as Alexander says), but it demonstrates the fact
> that the change need not
On Thu, Sep 22, 2016 at 4:37 PM, Alexander Belopolsky <
[email protected]> wrote:
> On the second thought, why can't the parser simply replace A with 'A' in
> annotations that appear in the body of class A? This will only break
> somewhat pathological code that defines A before it is
On Thu, Sep 22, 2016 at 4:43 PM, Alexander Belopolsky <
[email protected]> wrote:
>
> On Thu, Sep 22, 2016 at 4:37 PM, Alexander Belopolsky <
> [email protected]> wrote:
>
>> On the second thought, why can't the parser simply replace A with 'A' in
>> annotations that appe
On 22 September 2016 at 22:02, אלעזר wrote:
> On Thu, Sep 22, 2016 at 10:58 PM David Mertz wrote:
>
>> On Thu, Sep 22, 2016 at 12:35 PM, אלעזר wrote:
>>
>>> 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 ann
On Fri, Sep 23, 2016 at 12:05 AM Ivan Levkivskyi
wrote:
> On 22 September 2016 at 22:02, אלעזר wrote:
>
>> On Thu, Sep 22, 2016 at 10:58 PM David Mertz wrote:
>>
>>> On Thu, Sep 22, 2016 at 12:35 PM, אלעזר wrote:
>>>
I think we're talking about different things here. I just referred to
>>
On Fri, Sep 23, 2016 at 6:48 AM, Alexander Belopolsky
wrote:
> On the third thought, this entire feature can be implemented in the
> metaclass by injecting A = 'A' in the dict in __prepare__.
That would be the easiest, and least magical, solution. It simply
means that the name of the current clas
On Fri, Sep 23, 2016 at 12:18 AM Chris Angelico wrote:
> # Recursion in functions
> def spam():
> return spam()
>
I just note that it *is* surprising, for most users, that you can't be sure
that this is a recursion, yet. So it if you want a trusted-upon recursion
you should write
# spam:
de
On Fri, Sep 23, 2016 at 7:33 AM, אלעזר wrote:
> On Fri, Sep 23, 2016 at 12:18 AM Chris Angelico wrote:
>>
>> # Recursion in functions
>> def spam():
>> return spam()
>
>
> I just note that it *is* surprising, for most users, that you can't be sure
> that this is a recursion, yet. So it if you
On 23 September 2016 at 05:58, David Mertz wrote:
> On Thu, Sep 22, 2016 at 12:35 PM, אלעזר wrote:
>>
>> 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) -
On Fri, Sep 23, 2016 at 4:17 AM Nick Coghlan wrote:
...
> As others have noted, the general idea of allowing either a
> placeholder name or the class name to refer to a suitable type
> annotation is fine, though - that would be a matter of implicitly
> injecting that name into the class namespace
On Thu, Sep 22, 2016 at 09:33:58PM +, אלעזר wrote:
> On Fri, Sep 23, 2016 at 12:18 AM Chris Angelico wrote:
>
> > # Recursion in functions
> > def spam():
> > return spam()
> >
>
> I just note that it *is* surprising, for most users, that you can't be sure
> that this is a recursion, yet
On Fri, Sep 23, 2016 at 12:35 PM, Steven D'Aprano wrote:
> The straight-forward and simple way of writing a recursive spam()
> function surprises beginners, but they might go years or their entire
> career without running into a situation where they are caught by
> surprise. After all, it is rare
On Thu, Sep 22, 2016 at 07:21:18PM +, אלעזר wrote:
> On Thu, Sep 22, 2016 at 9:43 PM Steven D'Aprano wrote:
>
> > On Thu, Sep 22, 2016 at 05:19:12PM +, אלעזר wrote:
> > > Hi all,
> > >
> > > Annotations of function parameters and variables are evaluated when
> > > encountered.
> >
> > Rig
On 9/22/2016 10:54 PM, Chris Angelico wrote:
On Fri, Sep 23, 2016 at 12:35 PM, Steven D'Aprano wrote:
The straight-forward and simple way of writing a recursive spam()
function surprises beginners, but they might go years or their entire
career without running into a situation where they are ca
On 23 September 2016 at 12:05, אלעזר wrote:
> On Fri, Sep 23, 2016 at 4:17 AM Nick Coghlan wrote:
> ...
>>
>> As others have noted, the general idea of allowing either a
>> placeholder name or the class name to refer to a suitable type
>> annotation is fine, though - that would be a matter of imp
On 23 September 2016 at 13:06, Steven D'Aprano wrote:
> On Thu, Sep 22, 2016 at 07:21:18PM +, אלעזר wrote:
>> "Expression" is something that you need its value right
>> now, and "annotation" is something that, well, annotates the code you see
>> right now.
>
> Right. In the case of Python, fun
אלעזר wrote:
it feels like a
placeholder for this meaning would be better. E.g.:
class A:
def __add__(self, other: CLS) -> CLS: ...
That's fine for a class that refers to itself, but
what about classes that refer to each other? This
only addresses a small part of the probl
On 23 September 2016 at 15:50, Greg Ewing wrote:
> אלעזר wrote:
>>
>> it feels like a
>> placeholder for this meaning would be better. E.g.:
>>
>> class A:
>> def __add__(self, other: CLS) -> CLS: ...
>
>
> That's fine for a class that refers to itself, but
> what about classe
33 matches
Mail list logo
