Style question on recursive generators

[Alex Martelli]

Dima Dorfman <null at trit.org> wrote:
   ...
> >     a, b, c, *d = e
> 
> Both of these are intuitive to me. I'm generally in favor of expanding
> the use of '*' to mean aggregation in this manner, but someone else is
> gonna have to organize the crusade if they want one.

It will take an able and subtle spokesman, for it IS currently out of
favour (and the prospect of no language changes in 2.4->2.5, just like
we had none in 2.2->2.3, appears quite possible).


> > where d gets (an iterator for) 'the rest of e' after the first three
> > items of e are unpacked to a, b, and c.
> 
> FWIW, the implementation for the unpacking case is mostly straight-
> forward (I did one a while back). The only caveat is what to do with
> *d. You suggest storing an iterator for the rest of e, but this is
> unuseful if e is a real sequence, like a tuple. It's easy enough to
> special-case tuples and lists, but what about other user-defined
> types? Maybe slice off the rest? Real iterators (iter(x) is x) would
> have to be treated specially in any case.

I hate, detest, and abhor specialcasing anything.  "Special cases are
not special enough to break the rules".  'filter' (which specialcases
some kinds of sequences, while returning a list for all others) is a
good example of the kind of thing I believe should be avoided.

Leaving d as an iterator over the rest of e is something that is
extremely simple to explain and implement.  Explaning that 'd is a list,
string or tuple if that's the type of e; otherwise, if e supplies
__getitem__ AND that getitem accepts a slice object with None values for
stop and step, or alternatively if e supplies a __getslice__ method
that's callable with None as the stop argument, then d is e[3:]; in
other cases, d is an iterator over the rest of e' is just the kind of
thing that sends shivers through every fiber of my being.  Maybe it's
because I've had to write enough of those GD 'caveats' in the Nutshell,
enough to show me that there are already too many special cases... I
want to _get rid_ of the existing ones (once backwards compatibility can
be broken), definitely *NOT* add more 'convenient' ones...!!!-)

Saving a once-in-a-blue-moon 'd = list(d)' followup statement, or the
like, is just not worth this kind of aggravation, IMHO.


Alex