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@email.com Mobile: 0409 573 268 | http://www.talkinboutstuff.net "Let go your prejudices, lest they limit your thoughts and actions."