[Python-ideas] The Return of Implicit Lambda (Re: Allowing breaks in generator expressions by overloading the while keyword)

[Ryan Gonzalez]

On Fri, Feb 21, 2014 at 4:02 PM, Andrew Barnert <abarnert at yahoo.com> wrote:

> From: Ryan Gonzalez <rymg19 at gmail.com>
> Sent: Friday, February 21, 2014 1:36 PM
>
>
> >On Fri, Feb 21, 2014 at 2:34 PM, Andrew Barnert <abarnert at yahoo.com>
> wrote:
> >
> >From: Nick Coghlan <ncoghlan at gmail.com>
> >>
> >>Sent: Friday, February 21, 2014 4:18 AM
> >>
> >>
> >>> 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
> >>
> >>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 at 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?
>
>
> Doesn't that just make it even _more_ like perl, where arguments are
> always passed as an array?
>
> Anyway, presumably you mean that this:
>
>     lambda *args: args[0] * x**2 + args[1] * x + args[2]
>
> ... could be written as:
>
>     : ?[0] * x**2 + ?[1] * x + ?[2]
>
>
> I think that's horribly unreadable--partly because of the use of *args in
> the first place, and partly because ?[0] looks too... perlesque.
>
> I think the best answer is the one I suggested above--and which I think
> Nick implicitly assumed because he's smart enough to get there directly: At
> least initially, just do 0-argument and 1-argument lambdas. As long as you
> leave the door open for extended syntaxes in a future proposal, we don't
> need to figure them out yet.
>

The question mark still looks like Perl.

What about a reserved word instead?

-- 
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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140221/4acbf77e/attachment.html>