list equal to subclass of list?

[Roy Smith]

On May 12, 2011, at 11:30 AM, Eric Snow wrote:

> On Thu, May 12, 2011 at 6:23 AM, Roy Smith <roy at panix.com> wrote:
> The docs say:
> 
> [http://docs.python.org/library/stdtypes.html]
> Objects of different types, except different numeric types and different
> string types, never compare equal
> 
> [http://docs.python.org/release/2.7/reference/expressions.html#notin]
> objects of different types (emphasis)always compare unequal
> 
> 
> That definitely makes it unclear.

I don't think it's unclear at all.  It's very clear.  Clearly wrong :-)

> A little further down it says that you can customize comparison with the __cmp__ special method.

Yes, and that says:

The operators <, >, ==, >=, <=, and != compare the values of two objects. The objects need not have the same type. If both are numbers, they are converted to a common type. Otherwise, objects of different types always compare unequal, and are ordered consistently but arbitrarily. You can control comparison behavior of objects of non-built-in types by defining a __cmp__ method or rich comparison methods like __gt__, described in section Special method names.

I read that as saying that if you implement __eq__(), you must make sure that it returns False if self and other have different types (and likewise, __ne__() should return True for that case).  The same way that it says that obj1.__lt__(obj2) must return a consistent result for all types of obj1 and obj2.

> Looking over the documentation, it seems like it could be touched up to alleviate any confusion.  Perhaps rewording to make it clear that the described behavior is the default for objects, rather than always the case.

That would be a start, but doesn't address this specific problem.  If the docs are changed to say that "type(obj1) != type(obj2) implies obj1 != obj2" in only the default, people will assume that list follows this default rule since it's a built-in type.  Built-in types which don't follow the default rule need to have their behavior documented.

---
Roy Smith
roy at panix.com





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20110512/79b44a4e/attachment-0001.html>