[Python-Dev] Re: Single- vs. Multi-pass iterability

[David Abrahams]

From: "Guido van Rossum" <guido@python.org>

> > Do you intend to have a test for "is this an iterator" at all?
>
> Not right now, see the rest of my email.  The best you can do is check
> for a next method and hope for the best.

I only asked because the rest of your email seemed to imply that you didn't
believe in such checks at this time, while the sentence above my question
seemed to imply there is/should be such a test. Thanks for clarifying.

> > If LBYL is bad, what is introspection good for?
>
> Ask Alex.

OK. Alex, what's introspection good for?

> > I understand that that's always been "the Python way". However,
> > isn't there also some implication that some of the special functions
> > are more than just a way to provide implementations of Python's
> > syntax?
>
> Like what?
>
> > Notes in the docs like those on __getitem__ tend to argue
> > for that, at least by convention.  Unless I'm misinterpreting
> > things, "the Python way" isn't quite so one-sided where protocols
> > are concerned.
>
> Can you quote specific places in the docs you read this way?

Just for example:

__getitem__:

"For sequence types, the accepted keys should be integers and slice
objects.  .... If key is of an inappropriate type, TypeError may be raised;
if of a value outside the set of indexes for the sequence (after any
special interpretation of negative values), IndexError should be raised.
Note: for loops expect that an IndexError will be raised for illegal
indexes to allow proper detection of the end of the sequence. "


__delitem__:

"Same note as for __getitem__(). This should only be implemented for
mappings if the objects support removal of keys, or for sequences if
elements can be removed from the sequence. The same exceptions should be
raised for improper key values as for the __getitem__() method."

__iter__:

"This method should return a new iterator object that can iterate over all
the objects in the container. For mappings, it should iterate over the keys
of the container, and should also be made available as the method
iterkeys()."

The way I read these, the behavior of an implementation of these functions
isn't really open-ended. It ought to follow certain conventions, if you
want your type to behave sensibly. And that's about as strong as any
legislation I've seen anywhere in the Python docs.

> I don't
> see it, but I've only scanned chapter 3 of the Language Reference
> Manual.
>
> > Just for the record, I never meant to imply that it was broken, only
> > that I'd like to get a little more from it than I currently can.
>
> Maybe I should read Ping's email.  From the discussion I figured he
> was arguing this way.  I think you have to settle with what I proposed
> at the top.

Of course I do; I never expected otherwise. Like most of my other
suggestions, this is a case of "OK, whatever you say Guido... but as long
as people are interested in discussing the issues I'd like them to
understand my reasons for bringing it up".

-Dave