transforming a list into a string

[Christopher T King]

On Sun, 1 Aug 2004, Tim Peters wrote:

> The difference is that list() creates a concrete list object from its
> argument, but there's no such thing as "a concrete iter object". 

You've got me there.

> Iteration is a protocol, not a type.  iter(obj) invokes
> obj.__iter__(),

Only if obj.__iter__() is defined; otherwise it makes something up using 
__getitem__ as appropriate.

> and I don't know of any existing __iter__ implementation that returns an
> object that supports slicing.

True.  Built-in classes (such as list & tupleiterator) would have to be 
extended with this function (trivial if they all subclass from a common 
base class).  As to user classes, I'm proposing this on the assumption 
that a programmer would implement their own __getitem__ (I've been saying 
__getslice__ previously, __getitem__ is what I should be saying) if the 
functionality is so desired, which can be as trivial as setting 
__getitem__=islice, provided islice is extended to accept slice objects.  
Though, this would break __getitem__ in the case of getting a single 
item (I can see where this is heading)...

> 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.

You've made your point.  I guess this will just have to go on the "it 
would be neat if it worked this way, but it just doesn't" list for now ;)