On 21 February 2014 20:24, Steven D'Aprano <steve@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@gmail.com | Brisbane, Australia