[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 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?

-- 
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/2dc201c9/attachment-0001.html>