New-style classes, iter and PySequence_Check

[Raymond Hettinger]

[Tuure Laurinolli]
> Someone pasted the original version of the following code snippet on
> #python today. I started investigating why the new-style class didn't
> work as expected
> classes apparently don't return true for PyInstance_Check, which causes
> a problem in PySequence_Check, since it will only do an attribute lookup
>   for instances.
>
> Things probably shouldn't be this way. Should I go to python-dev with this?

PyInstance_Check is defined as checking for instances of old style classes.
Hence, it appropriate that it does not return True for instances of new-style
classes.

PySequence_Check is pretty good shape.  In general, it is not always possible to
tell a mapping from a sequence, but the function does try to take advantage of
all available information.  In particular, it has a separate code path for
new-style instances which sometimes have additional information (i.e. dict and
its subclasses fill the tp_as_mapping->mp_subscript slot instead of the
tp_as_sequence->sq_slice slot).

Old style classes never inherit from dict, tuple, list, etc. so that slot
distinction isn't meaningful.  Accordingly, PySequence_Check simply checks to
see if an object defines __getitem__ and that check entails an attribute lookup.
The posted code snippet uses a __getattr__ gimmick to supply an affirmative
answer to that check.

The docs do not make guarantees about how iter(o) will determine whether object
o is a sequence.  Currently, it does the best it can and that entails having
different implementation logic for new-style and old-style objects as described
above.  The provided snippet uses the __getattr__ gimmick to reveal the
implementation specific behavior.  Mystery solved.

In contrast, the docs do make guarantees about explicit attribute lookup (i.e.
that an attribute lookup will actually occur and that slot checking logic will
not be substituted).  The posted snippet reveals that these guarantees are
intact for both new and old-style classes.

Knowing all of this reveals the behavior to be a feature rather than a bug -- 
the feature being that operator.IsMappingType and operator.IsSequenceType do a
remarkable job (few false positives and no false negatives) across a huge
variety of object types.  It has been tested with instances of set, int, float,
complex, long, bool, str, unicode, UserString, list, UserList, tuple, deque,
NoneType, NotImplemented, new and old style instances with and without defining
__getitem__.  Also, tested were subclasses of the above types.  The false
positives are limited to user defined classes (new or old-style) defining
__getitem__.   Since the mapping API overlaps with the sequence API, it is not
always possible to distinguish the two.

Of course, you found that it is possible to throw a monkey wrench in the process
using __getattr__ to exploit undefined, implementation specific behavior.  Don't
do that.  If a class needs to be iterable, then supply an __iter__ method.  If
that method needs to be retargeted dynamically, then
take advantage of the guarantee that iter(o) will always find a defined __iter__
method.  Perhaps, define __iter__ as lambda obj:  obj(obj.__getattr__(obj,
'__iter__')) or somesuch.  IOW, to guarantee that iter() performs an __iter__
lookup, fill the slot with something that does that lookup.


Raymond Hettinger


E = mc**2      # Einstein
E = IR         # Ohm's law
 therefore
IR = mc**2     # Raymond's grand unified theory