[Python-Dev] Re: accumulator display syntax

Nick Coghlan ncoghlan at iinet.net.au
Mon Oct 20 10:37:48 EDT 2003


Alex Martelli strung bits together to say:
> On Monday 20 October 2003 03:22 pm, Nick Coghlan wrote:
> Yes, you COULD extend the syntax from Greg's
>> NAME 'of' listmaker
>> to _also_ accept
>> NAME 'of' test
>> or thereabouts (in the terms of dist/src/Grammar/Grammar of course), I don't
> think it would have any ambiguity. As to whether it's worth it, I dunno.

Actually, I was suggesting that if 'of' is simply designated as taking a list* 
on the right hand side, then you can just write a list comprehension there, 
without needing the parser to understand the 'for' syntax in that case. But I 
don't know enough about the parser to really know if that would be a saving 
worth making.
(* a list is what I was thinking, but as you point out, an iterable would be better)
>> sum of xvalues
>> Nope, he's summing the _squares_ --
> sum of x*x for x in xvalues
> it says.

D'oh - and I got that one right higher up, too. Ah, well.
>> maximum of [f(x, y) for x in xrange for y in yrange]
>> Yes, you could put brackets there, but why?

I though it would be easier on the parser (only accepting a list/iterable on the 
right hand side). I don't know if that's actually true, though.
>> top(10) of [humour(joke) for joke in comedy]
>> Ditto -- and it doesn't do the job unless the magic becomes even blacker.
> top(N) is supposed to return jokes, not their humor values; so it needs to
> get an iterable or iterator of (humor(joke), joke) PAIRS -- I think it would
> DEFINITELY be better to have this spelled out, and in fact I'd prefer:
>> top(10, key=humour) of comedy
>> or
>> top(10, key=humour) of joke for joke in comedy
>> using the same neat syntax "key=<callable>" just sprouted by lists' sort 
> method.

Yes, that would make it a lot clearer what was going on.
> Agreed on the prettiness. I would prefer to have the special method be 
> defined to receive "an iterator or iterable" -- so we can maybe put together
> a prototype where we just make and pass it a list, BUT keep the door open to
> passing it an "iterator comprehension" in the future. Or maybe make it always
> an iterator (in the prototype we can just build the list and call iter on it 
> anyway... so it's not any harder to get started playing with it).

Well, I think we've established that at least two people on the planet love this 
idea. . . and agreed on the iterator/iterable vs lists, too. I only thought of 
that distinction after I'd already hit send :)
> Oh BTW, joining another still-current thread --
>> for x in sorted_copy of mylist:
> ...
>> now doesn't THAT read just wonderfully, too...?-)

Not to mention:
 for x in sorted_copy of reversed_copy of my_list:
 ...
 for x in sorted_copy(key=len) of my_list:
 ...
Indeed, _that_ is a solution that looks truly Pythonic!
Hmm, just had a strange thought:
 y = copy of x
How would that be for executable pseudocode? It's entirely possible to do all 
the iterator related things without having this last example work. But what if 
it did?
Cheers,
Nick.
__of__: just a single-argument function call?
-- 
Nick Coghlan | Brisbane, Australia
ICQ#: 68854767 | ncoghlan at email.com
Mobile: 0409 573 268 | http://www.talkinboutstuff.net
"Let go your prejudices,
 lest they limit your thoughts and actions."


More information about the Python-Dev mailing list

AltStyle によって変換されたページ (->オリジナル) /