[Python-Dev] accumulator display syntax

[Phillip J. Eby]

At 09:53 AM 10/17/03 +0200, Alex Martelli wrote:
>What about this latest small change, of having the indexing syntax
>invoke __getitem__ -- just like any other indexing, just with an
>iterator as the index rather than (e.g.) a tuple of slices etc?
>
>What, if anything, is "very confusing" in, e.g.,
>
>     sum[x*x for x in blaap]
>
>compared with e.g. the currently accepted:
>
>     a['tanto':'va':'la', 'gatta':'al':'lardo']
>
>?

Because it's arguably bad coding style to use slices or indexes on an 
object in order to perform a function on the indexes supplied.  Wouldn't 
you find a program where this held true:

    TimesTwo[2] == 4

to be in bad style?  Function calls are for transforming arguments, 
indexing is for accessing the contents of a *container*.  Top(10) is not a 
container, it has nothing in it, and neither does TimesTwo.  I suppose you 
could argue that TimesTwo is a conceptual infinite sequence of even 
integers, but for most of the proposed accumulators, similar arguments 
would be a *big* stretch.

Yes, what you propose is certainly *possible*.  But again, if you really 
needed an iterator as an index, you can right now do:

sum[ [x*x for x in blaap] ]

And if there are gencomps, you could do the same.  So, why single out 
subscripting for special consideration with regard to generator 
comprehensions, thus forcing clever tricks of questionable style in order 
to do what ought to be function calls?

I shudder to think of trying to have to explain Top(10)[...] to a Python 
newbie, even if they're an experienced programmer.  Because Top(10) isn't a 
*container*.  I suppose a C++ veteran might consider it an ugly operator 
overloading hack...  and they'd be right.  Top(10,[...]) on the other hand, 
is crystal clear to anybody that gets the idea of function calls.