[Python-Dev] Re: accumulator display syntax

[Alex Martelli]

On Friday 17 October 2003 08:17 pm, Terry Reedy wrote:
   ...
> > >>> foo[ 'va':23:2j, {'zip':'zop'}:45:(3,4) ]
> >
> > (slice('va', 23, 2j), slice({'zip': 'zop'}, 45, (3, 4)))
> >
> > Not particularly _sensible_, mind you, and I hope nobody's yet
   ...
> In your commercial programming group, would you accept such a slice
> usage from another programmer, especially without prior agreement of
> the group?  Or would you want to edit,  as you would with 'return x<y
> and True or False' and might with 'return x<z and 4 or 2'?  If you

Such slice usage would presumably be made necessary by the behavior
of foo's type -- that indexing would cause errors with all types I've ever
seen actually used, so, if it were used in production code, it would no
doubt have to be because foo's type requires weird indexing.  Now, I'd
_like_ to say that no external component with such weird behavior would
ever be tolerated in any group I work for... BUT, given that I've had to
write programs using "external components" such as the win32 API's,
MS Office, etc (and may well still have to use others such as OO's new
Python interface -- almost makes one nostalgic for MS Office...:-), if I
said that I'd be lying:-).

Seriously, I can't imagine how such weird interface requirements might
ever end up piled onto indexing in particular (though, come to think of
it, some "indexed properties" in some COM object models... eeek... well,
not QUITE that bad!-).  But the point is quite another: by composing
elementary and perfectly sensible language elements (slices, generalized
indexing) it IS quite possible, even today, to write weird things.  This is
no argument for removing the perfectly sensible elements from the
language, just as the possible abuses of 'and' and 'or' don't mean we
should in general do without THEM.

> would reject it in practice, then it is hardly an argument for
> something arguably even odder.

I'm happy to be using a language which supplies good elementary
components and good general "composability", even though it IS
possible to overuse the composition and end up with weird constructs.
Personally, I don't think that allowing comprehensions in indices would
be particularly odd: just another "good elementary component".  So
would "iterator comprehensions", as an alternative.  Both of them
quite usable in composition with other existing components and rules
to produce weirdness, sure: but showing that weirdness is already
quite possible whether new constructs are allowed or not appears to
me to be a perfectly valid argument for a new construct that's liable
to be used in either good or weird ways.


Alex