[Python-Dev] Re: accumulator display syntax

[Nick Coghlan]

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."