[Python-ideas] Allowing breaks in generator expressions by overloading the while keyword

[Nick Coghlan]

On 21 February 2014 23:03, M.-A. Lemburg <mal at egenix.com> wrote:
> On 21.02.2014 13:25, Nick Coghlan wrote:
>> On 21 February 2014 22:18, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> That's not very readable to most Python programmers, but what if you
>>> could write something like:
>>>
>>>     isprime = all(n % p for p in takewhile((: ? ** 2 < n), primes_seen))
>>>
>>> This is somewhat similar to the implicit lambda proposal in
>>> http://legacy.python.org/dev/peps/pep-0312/, but with the following
>>> two essential differences:
>>>
>>> 1. The parentheses would be required (as per generator expressions,
>>> and as is being discussed for except expressions)
>>> 2. By using a "?" token within the implicit lambda, you would create a
>>> lambda that takes a single argument. If there is no such token, then
>>> it would take no arguments.
>>
>> Oh, and under such a proposal, the generator expression:
>>
>>     (x for x in seq)
>>
>> would be semantically equivalent to:
>>
>>     (: yield x for x in ?)(seq)
>>
>> Currently, there's no underlying construct you can decompose a
>> generator expression into, because there's no notation for a lambda
>> expression with an anonymous parameter.
>
> Hmm, this reminds me too much of regular expression syntax :-)
>
> I wonder why people are so keen on stuffing too much logic into
> a single line. Must be a twitter/SMS side-effect.
>
> Programs don't get faster that way, they don't get more readable,
> you don't get to do more things that couldn't do otherwise
> and requiring a master in computer science to be able to understand
> what goes on in one of those magical lines doesn't feel right
> to me either, given that we are promoting Python as first
> programming language.
>
> Of course, tossing around ideas like these is fun and I don't
> want to spoil it. Eventually something useful will come out of
> these discussions, I'm sure :-)

The reason I keep beating my head against this particular wall (cf.
PEP 403's @in clauses and PEP 3150's given suites) is that my personal
goal for Python is that it should be a tool that lets people express
what they are thinking clearly and relatively concisely.

As far as I have been able to tell, the persistent requests for
"multi-line lambdas", cleaner lambda syntax, etc, are because Python
doesn't currently make it easy to express a lot of operations that
involve higher order manipulation of "one shot" callables  - closures
or custom functions where you *don't* want to re-use them, but Python
still forces you to pull them out and name them. I think PEP 403 is my
best current description of the mental speed bump involved:
http://www.python.org/dev/peps/pep-0403/

Decorators are an example where this used to be a problem (compounded
by other issues related to repeating the name multiple times):

    def f(cls):
        ...
    f = classmethod(f)

But this was replaced by the much cleaner:

    @classmethod
    def f(cls):
        ...

Like try/except/finally -> with statements, decorators replaced a
"bracketed" construct with a "prefix" only construct, greatly
improving the readability in the process.

Extracting a named one-shot function inline is problematic in much the same way:

    def custom_key(v):
        # Helper for a sorted call you don't know is coming yet
        ...
    x = sorted(seq, key=custom_key) # Oh, that's what it is for

The idea behind both PEP 403 and 3150 is to be able to do a similar
bracketed -> prefix only transformation for more constructs where the
callable is incidental to the real operation. The PEP 403 approach to
custom key functions:

    @in x = sorted(seq, key=custom_key)
    def custom_key(v):
        ...

I'm not actually happy with the PEP 403 syntax (or the complexity of
PEP 3150), but I think the problem they both attempt to solve is one
worth having a better answer for. I just haven't figured out what that
answer might look like yet (and neither has anyone else) :P

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia