[Python-Dev] accumulator display syntax

[Alex Martelli]

On Friday 17 October 2003 02:07 am, Greg Ewing wrote:
> Alex Martelli <aleaxit at yahoo.com>:
> > Then list comprehensions were introduced and the syntax admitted
> > inside [ ] got far wider, in "list display" cases only.  Why would it be
> > a problem if now the syntax admitted in the "similar syntax, different
> > semantics" case of "indexing" got similarly wider?
>
> List comprehensions extended the semantics of list construction by
> providing new ways to specify the contents of the list.
>
> Extended slice notation extended the semantics of indexing by
> providing new ways to specify the index.
>
> What you're proposing hijacks the indexing syntax and uses it to mean
> something completely different from indexing, which is a much bigger
> change, and potentially a very confusing one.

Hmmm -- on this thread I meant to discuss the syntax only, but, OK,
let's touch on the semantics.  Let's say, then, that my proposed syntax:
    foo[x*x for x in blah]
gets turned into "extending the semantics of indexing" just like, e.g.,
extended slicing did.  That basically requires making this syntax
correspond to Python calling:
    type(foo).__getitem__(foo, <some suitable object>)
just like it does for other possible contents of the parentheses.

E.g., today:

>>> class x(object):
...   def __getitem__(self, index): return index
...
>>> a = x()
>>> print a['tanto':'va':'la', 'gatta':'al':'lardo']
(slice('tanto', 'va', 'la'), slice('gatta', 'al', 'lardo'))
>>>

while hypothetically if this syntax (and corresponding semantics) were
adopted, we might have:

>>> print a[x*x for x in blaap]
<indexing iterator object at 0x402deeac>

Of course, it would be up to a's type x to know what to do with
that iterator, just as, today, it is to know what to do with that
tuple of slice objects with (e.g.) string attributes.  Coding objects
that support iterators as indices would be slightly harder than
having objects receive such indexing via a separate special method,
such as the previously proposed __accum__; but then, this just
corresponds to the slight hardship we pay for generality in coding
objects that support slices as indices via __getitem__ -- the older
and less general approach of having a separate special method,
quondam __getslice__, was easier for special cases but not as
general and extensible as today's.

So, if framing what the subject still calls "accumulator displays"
as "new ways to specify the index" -- and renaming the whole
concept to e.g. "iterators as indices", since there is no necessary
connection of the proposed new syntax and semantics to
accumulation -- can ease acceptance, that's fine with me.  So
is the collapsing of the arguments into a single iterator, rather
than a separate pair of underlying iterator and exp callable to
be applied to each item -- this requires changing the Top(10)
use case to pass both sort-key and item explicitly:

Top(10)[ (humor(joke), joke) for joke in jokes ]

with Top having semantics roughly equivalent to (though no
doubt easily optimized -- by using a heap -- wrt):

def Top(N):
    class topper(object):
        def __getitem__(self, iter):
            values_and_items = list(iter)
            values_and_items.sort()
            return [ item for value, item in values_and_items[:N] ]
    return topper()

But this may in fact be preferable wrt both my and Peter
Norvig's previous ideas as posted on this thread.


> So, no, sorry, it doesn't overcome my objection!

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']

?


Alex