transforming a list into a string

[Dan Christensen]

Tim Peters <tim.peters at gmail.com> writes:

> The only thing required of __iter__ is that it return an object that
> supports the iteration protocol (meaning an object that supports
> next() and __iter__() methods).  So again, adding the ability to
> slice too would mean requiring more of __iter__ methods -- or
> changing the implementation of iter() to ignore __iter__ methods and
> make something up itself.  It's A Visible Change no matter how you
> cut it.

What if object[a:b:c] did the following?

1) if __getslice__ is supplied by object, use it.
2) if __getitem__ is supplied, use it.
3) if __iter__ is supplied, use islice(__iter__(object),slice(a,b,c)).

(IIUC, 1) and 2) are what is done currently.  As Christopher pointed
out, for 3) to work, islice would have to modified to accept a slice.)

Would this be backward compatible (a "Visible Change"), or would it
break something?

It seems to parallel other dispatching mechanisms, e.g. (IIUC) "in" is
implemented just using the iterator protocol, unless the object
supplies __contains__.

I like the idea of not needing to know about islice, and just using
the [a:b:c] notation.  One of python's strongest features is its
consistency of notation.

Dan