[Python-ideas] FW: Map-then-filter in comprehensions

Joseph Jevnik joejev at gmail.com
Tue Mar 8 15:50:27 EST 2016


Currently `_` is not a keyword or special in any way. How do we resolve the
ambiguity with:

_ = 10
[x for x in xs if _ > 10]

On Tue, Mar 8, 2016 at 3:46 PM, Mark Mollineaux <bufordsharkley at gmail.com>
wrote:

> This map-then-filter shortcoming is one of the most common warts I
> encounter with python syntax, and I would absolutely love an improvement
> here.
>
> I think ChrisA is closest with:
>
> > I'm really not liking the proposed syntax, but maybe there's an alternative.
> My first thought on reading this proposal is: "Ah, it's like SQL's
> 'HAVING' keyword". The trouble is that SQL can identify its columns, but
> Python doesn't have an easy syntax for "the thing you're about to
> return". Something like:
> >
> > [abs(x) for x in numbers having _ > 5]
>
> But I wonder, why not just:
>
> [abs(x) for x in numbers if _ > 5]
>
> Where _ refers to the return expression within a comprehension, and is
> interpreted specially in this context?
>
>
> On Tue, Mar 8, 2016 at 7:20 AM, Chris Angelico <rosuav at gmail.com> wrote:
>
>> On Wed, Mar 9, 2016 at 1:59 AM, Émanuel Barry <vgr255 at live.ca> wrote:
>> > I’m going be confused by what sort of name binding it does. A quick
>> glance
>> > at the keywords list tells me that no currently-existing keyword is “the
>> > obvious choice” for this purpose. I don’t think such a small niche
>> warrants
>> > a new keyword, either.
>>
>> Maybe a pseudo-keyword would be sufficient - comprehension/genexp
>> syntax is pretty solidly specified, so it's less likely to break stuff
>> than in general syntax.
>>
>> I'm really not liking the proposed syntax, but maybe there's an
>> alternative. My first thought on reading this proposal is: "Ah, it's
>> like SQL's 'HAVING' keyword". The trouble is that SQL can identify its
>> columns, but Python doesn't have an easy syntax for "the thing you're
>> about to return". Something like:
>>
>> [abs(x) for x in numbers having _ > 5]
>>
>> The semantics would be equivalent to:
>> def <listcomp>():
>>     result = []
>>     for x in numbers:
>>         _ = abs(x)
>>         if _ > 5: result.append(_)
>>     return result
>>
>> A 'having' clause (and, by the way, I'm not too enthused about the
>> name, but I'm using it as a placeholder because of SQL's use) would
>> have to go after all 'for' and 'if' clauses, and would have access to
>> one special name (maybe _ because of its use in interactive mode, or
>> maybe something else) which holds the value that would be returned. A
>> simple filter-out-the-false-ones could do this:
>>
>> [regex.match(line) for line in lines having _]
>>
>> Of course, people could just switch from 'if' to 'having' across the
>> board, but this has the same consequences that it does in SQL: now
>> *every* row has to be fully processed, only to be discarded at the
>> last step. Using 'having' with no underscore would violate common
>> sense and good style.
>>
>> ChrisA
>> _______________________________________________
>> 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/
>
>
>
> _______________________________________________
> 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/20160308/f7a8a01a/attachment-0001.html>


More information about the Python-ideas mailing list