[Python-ideas] Dart-like method cascading operator in Python

[Perešíni Peter]

On Fri, Nov 22, 2013 at 10:16 AM, Bruce Leban <bruce at leapyear.org> wrote:

>
> Steven D'Aprano:
>
> >> Perhaps, but that's not relevant to the proposed syntax. The proposed
> syntax has more to do with "then" rather than "there", that is, "the
> last object used", not "the object at location 1234".
>
> >> For starters, you should explain precisely how the compiler will
> determine what is the "last object used" in practice. Your examples so far
> suggest it is based on the last line of source code, but that's tricky.
>
> Perešíni Peter:
>
> > I think the reasonable way to define it would be that the cascade
> operator will act only if the last thing (on the previous line) was an
> expression. In particular, all statements like "del y, for, while, if-else"
> followed by a cascade should be a parse error with the exception of the
> assignment which is a statement but we want to allow it. I am not sure
> about yield -- it can be a bit difficult to agree on the exact semantic
> there (e.g. should I yield first, then continue with the cascade or should
> I execute the whole cascade and yield as a final step?)
>
> I don't think that's well-defined at all. Furthermore last object on
> *previous* line is less useful than object on line that introduces the
> suite. Consider:
>
> obj::
>     ..x = b
>     # is last object b? That's not useful. obj.x? That may not be an object
>     ..y = 3
>     # even more clearly not useful
>     ..sort()
>     # this always returns None
>
> In:
>
> <expression>::
>     <lines all referencing that one expression via ..>
>
Yes, exactly. As usual I did not write my thoughts clearly. By the last
line I really meant "last object on the preceding line ending with ::
having the smaller indent than the current line"

> I know exactly what that does without reading each intervening line which
> could change the object being operated on. I can use this with objects that
> *don't* support chaining which is what makes it useful. I can reorder lines
> worrying only about method execution order not breaking chaining.
>
> The traceback complaint is a red herring as it can easily inject the line
> that has the expression being operated on.
>
> In summary I would only allow the first line to contain an expression or
> assignment which by definition has a single explicit value. That values is
> what all statements reference:
>
> obj::
>     ..x = 3
>     ..y()  # operates on obj not obj.x or 3
>     ..z(). # ditto
>
> a[index] = foo(...) ::  # don't need to repeat a[index] below or use a
> temporary name
>     ..x = 3
>     ..y()
>     ..z()
>
>>
>> I think the reasonable way to define it would be that the cascade
>> operator will act only if the last thing (on the previous line) was an
>> expression. In particular, all statements like "del y, for, while, if-else"
>> followed by a cascade should be a parse error with the exception of the
>> assignment which is a statement but we want to allow it. I am not sure
>> about yield -- it can be a bit difficult to agree on the exact semantic
>> there (e.g. should I yield first, then continue with the cascade or should
>> I execute the whole cascade and yield as a final step?)
>>
>>
> Actually, thinking about my own ideas -- the bigger problem than yield is
the return. I am not sure if things like

return list(range(10))
    ..reverse()
    ..pop(0)

should be allowed or not - having something being executed after the return
statement line might be a bit confusing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20131122/cd48a51d/attachment.html>