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

Nick Coghlan ncoghlan at gmail.com
Fri Feb 21 13:18:26 CET 2014


On 21 February 2014 20:24, Steven D'Aprano <steve at pearwood.info> wrote:
>
> but alas both Nick Coglan and (if I recall correctly) Guido have ruled
> that Python won't get this, so until the Revolution comes, it isn't
> going to happen.

It's not that it can't happen - it's that someone would need to build
a case of a similar calibre to the one Chris Angelico is currently
putting together for except expressions in PEP 463 :)

However, it's a *much* bigger challenge in this case, as
itertools.takewhile exists, whereas there's currently no way to do
exception handling as part of a larger expression without major
contortions.

Re-reading Andrew's post at
http://stupidpythonideas.blogspot.com.au/2013/07/syntactic-takewhile.html,
I'm actually more intrigued by Haskell's shorthand for lambda
functions that consist of a single binary operator.

Consider:

    isprime = all(n % p for p in takewhile((lambda p: p**2 < n), primes_seen))

Is there are a nicer way to write that? The Haskell equivalent is:

   (< n) . (** 2)

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.

However, the examples in that PEP are no longer useful, as they have
since been addressed by dedicated constructs (conditional expressions
in PEP 308 and context managers in PEP 343).

Note that I'm not saying this is a good idea. However, I am saying I
think it is an idea that may be worth exploring further to see if it
also addresses at least some of the use cases given in PEP's 403 and
3150 (especially in combination with PEP 463) by making custom key and
predicate functions easier to define.

Cheers,
Nick.

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


More information about the Python-ideas mailing list