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."
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4