[Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality

[Haoyi Li]

> The idea was never to start passing complex expressions around the place.
It was just to allow a function to take an expression containing about one
or two names, and evaluate the expression internally, so this...
>
> func(lambda foo: foo > 0)
>
> ...can become...
>
> func($foo > 0)

>>> from macropy.quick_lambda import macros, f, _
>>> map(f[_ + 1], [1, 2, 3])
[2, 3, 4]

>From an external API, it seems exactly the same. From an internal point of
view, you have to pass *foo* explicitly to the function you capture, but
I'd argue that that's probably a good thing in the majority of cases. There
are cases where you'd want to "evaluate the expression internally" to
automagically inject identifiers into the scope of the expression, but
those are few and far between.


On Wed, Mar 5, 2014 at 11:44 AM, Ryan Gonzalez <rymg19 at gmail.com> wrote:

> On Tue, Mar 4, 2014 at 8:36 PM, David Mertz <mertz at gnosis.cx> wrote:
>
>> On Tue, Mar 4, 2014 at 5:46 PM, Cameron Simpson <cs at zip.com.au> wrote:
>>
>>> >   foo = 1
>>> >   a = $(foo + 1)
>>> Definitely nicer. Still irrationally uncomfortable about the "$" though.
>>> A thought, though it could break existing code (and nested tuples, alas):
>>>
>>>     a = (( foo + 1 ))
>>>
>>
>> That looks like unresolvable ambiguity to me.  I confess that I am more
>> comfortable with '$(...)' because I'm one of those folks who actually likes
>> bash, and uses that spelling often over there (where the meaning isn't the
>> *same* as this, but is enough similar for the meaning to carry over)
>>
>>
>
> But this is Python, which is 10x better. And besides, that syntax gives me
> GNU make nightmares.
>
>
>>  Still, what does this mean?
>>>     a = 3 + (( foo + 1 ))
>>> I think that would need to be a syntax error, because I can't see it
>>> being
>>> anything except nonsense otherwise.
>>
>>
> I see it as:
>
> Create an anonymous function object that adds foo to 1. Then, try and add
> 3 to that resulting object(which obviously would fail). It'd be kind of
> like:
>
> a = 3 + (lambda: foo+1)
>
> a.k.a:
>
> def myfunc(): return foo+1
> a = 3+myfunc
>
> or(somewhat clearer in C++):
>
> SomeType a = 3 + [&]() { return foo+1; };
>
> It's a bit more obvious of the error in the C++ example(or, at least to
> me).
>
> ...
>> --
>> Keeping medicines from the bloodstreams of the sick; food
>> from the bellies of the hungry; books from the hands of the
>> uneducated; technology from the underdeveloped; and putting
>> advocates of freedom in prisons.  Intellectual property is
>> to the 21st century what the slave trade was to the 16th.
>>
>
>
>
> --
> 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."
>
>
> _______________________________________________
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140305/e9cf69e5/attachment.html>