General question about Python design goals

Mike Meyer mwm at
Fri Dec 2 00:06:53 CET 2005

"Fredrik Lundh" <fredrik at> writes:
> Mike Meyer wrote:
>>>> Seriously. Why doesn't this have to be phrased as "for x in list((1,
>>>> 2, 3))", just like you have to write list((1, 2, 3)).count(1), etc.?
>>> because anything that supports [] can be iterated over.
>> That's false. Anything that has __getitem__ supports []. To be
>> iterated over, it has to have __iter__, or an __getitem__ that works
>> on integers properly.
> your arguments are getting more and more antoon-like.  you can create
> an iterator (using iter) for any object that supports [] (__getitem__), but
> if __getitem__ doesn't do the right thing, any attempt to fetch items by
> calling it will of course fail as well.

So you're claiming that the ability to create an iterator for an
object via iter is sufficient to claim that you can iterate over it,
never mind that actually using the iterator fails?

Or are you claiming that a __getitem__ that doesn't handle integers
the way iter expects is somehow "wrong"? If so, what's up with

If you're claiming something else, you'll have to clarify it.

>> Writing a class that meets the first without
>> meeting the second is easy. Dicts used to qualify, and tuples could be
>> iterated over at that time.
>> Not really very satisfactory reasons.
> that's how python's sequence protocol works.  duck typing all the
> way down.

So it's an accident of implementation? Should iterating over a tuple
then be considered "abuse", because tuples aren't intended to be used
as a sequence?

I'm perfectly happy to accept that tuples aren't sequences, and that's
why they don't have sequence-like methods. But there really should be
a better explanation than "oops" for them having sequence-like
behavior elsewhere.

Mike Meyer <mwm at>
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

More information about the Python-list mailing list