[Python-Dev] Re: accumulator display syntax
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
(* 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
> top(10, key=humour) of joke for joke in comedy
> using the same neat syntax "key=<callable>" just sprouted by lists' sort
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
__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