On Fri, Feb 21, 2014 at 2:34 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
From: Nick Coghlan <ncoghlan@gmail.com>
Sent: Friday, February 21, 2014 4:18 AM
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
That's really not a shorthand for lambda, it's a combination of other features that make lambdas often unnecessary. I think the C++ boost::lambda example is a better fit:
_1 ** 2 < n
but what if you
could write something like:
isprime = all(n % p for p in takewhile((: ? ** 2 < n), primes_seen))
I like this. The ? is a lot better than the _ or _1 I suggested (especially to people who do a lot of SQL programming in Python and already use ? as an inline parameter), and using a colon makes it explicit without adding too much visual noise. The only concern is whether using up one of the handful of as-yet-unused ASCII symbols raises the bar a little too high...
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.
Would it be worth extending this to multiple arguments? I think it would be handy, but I can't think of any way to make it look nearly as good as the 0- and 1-arg forms.
Obviously this should still be a one-arg lambda that just uses its parameter repeatedly:
: ? * x**2 + ? * x + ?
Sticking a number on the ? looks terrible:
: ?1 * x**2 + ?2 * x + ?3
Looking at the other DB-API 2.0 param styles, this is hideous because of the way it uses colons twice:
: :1 * x**2 + :2 * x + :3
Something like this wouldn't be too bad, except that it already has a much more useful meaning, set literals:
: {1} * x**2 + {2} * x + {3}
So really, the best I can come up with is the boost::lambda version I already didn't like and you already dismissed without comment:
: _1 * x**2 + _2 * x + _3
On the other hand, any expression this complex--even with just one parameter--is already starting to look pretty bad as an implicit lambda, and the downsides of an explicit lambda go down the longer it gets. So maybe the best answer is:
lambda a, b, c: a * x**2 + b * x + c
Anyway, we can always start with just 0- and 1-argument forms and come back to expand the idea later, right?
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.
I'll start digging up some examples; it is hard to predict how nice this will look until we see it in a wide range of realistic code. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
+1 for the question mark. However, there's the problem of multi-argument lambdas. The ?(number) looks to much like Perl. What about something like ? being an array of arguments? -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."