transforming a list into a string

Tim Peters tim.peters at gmail.com
Mon Aug 2 02:51:15 CEST 2004


[Christopher T King]
> Ah, I see your point.  But most functions that expect iterators use iter()
> on them first (to iterize sequences), do they not?  So long as iter()
> supplies the necessary __getslice__ implementation, the world would be
> happy.  This situation would mirror the situation with list(): though a
> user-defined sequence might not implement __getslice__ (and still be
> usable as a list), the object returned by list() is guaranteed to.

The difference is that list() creates a concrete list object from its
argument, but there's no such thing as "a concrete iter object". 
Iteration is a protocol, not a type.  iter(obj) invokes
obj.__iter__(), and I don't know of any existing __iter__
implementation that returns an object that supports slicing.  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.



More information about the Python-list mailing list