[Python-ideas] Return expressions

Andrew Barnert abarnert at yahoo.com
Fri Nov 21 17:22:55 CET 2014



Sent from a random iPhone

On Nov 20, 2014, at 8:21, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 21 November 2014 01:49, MRAB <python at mrabarnett.plus.com> wrote:
>> 
>> 
>> On 2014-11-20 14:43, Petr Viktorin wrote:
>>> 
>>> The "while" expresses intent, "return" caters to low-level mechanics.
>>> The "nested compound statements" explanation is already not that good:
>>> why does the value come first, not last? For readability*. The
>>> difference between function/nested compound statements syntax and
>>> comprehension syntax is already so big, and the low-level "while
>>> x:"→"if not x: break" translation is so easy, that between the two the
>>> readability of "while" should win.
>> 
>> I can see the problem with 'while': if there are multiple 'for' parts, they are equivalent to nested
>> 'for' loops, so you might assume that a 'while' part would also be equivalent to a nested 'while'
>> loop, whereas it would, in fact, be controlling the preceding 'for' part.
>> 
>> In other words, it would be:
>> 
>>    for x in range(10) while x < 5:
>>        ....
>> 
>> but could be seen as:
>> 
>>    for x in range(10):
>>        while x < 5:
> 
> 
> PEP 3142 was the last attempt at asking this question - Guido isn't
> keen on the idea, so he rejected it the last time we did a pass
> through the PEPs that weren't being actively worked on.

The fact few times this has came up on -ideas or -dev, people suggested a variety of alternative syntaxes for this idea, just as is happening this time, and so far, they've always been subsets of the same ideas.

There are syntaxes that map nicely to the nested statement translation but don't read well, syntaxes that read well but make no sense as nested statements, syntaxes that sort of meet both those criteria but are so verbose nobody would use them, syntaxes that only make sense if everyone knows that comprehensions (including genexprs) are run inside their own hidden functions, syntaxes that only make sense if you pretend they aren't, syntaxes that require a change to normal for statements that wouldn't ever realistically be used there, and syntaxes that change the basic principle behind how comprehensions work. (And maybe my suggestion to make or stop() work in listcomps the same way fits in here, even though the goal was to unify the semantics of all genexprs and other comprehensions, rather than to provide this functionality.)

So far, Guido hasn't liked any of them, and none of them have gotten the kind of widespread buy-in from the community that seem likely to convince him to take another look. So it seems like a waste of time to rehash them every year or so.

Maybe what we need to do is update PEP 3142, gathering all of the alternative ideas, and expanding on the rationale, so Guido can reject that, and next time this comes up, everyone will have something to read before having the same arguments about the same proposals?


More information about the Python-ideas mailing list