checking if a list is empty

Steven D'Aprano steve+comp.lang.python at pearwood.info
Thu May 12 20:16:30 EDT 2011


On Thu, 12 May 2011 07:36:27 -0400, Roy Smith wrote:

> In article <931adaF9g1U1 at mid.individual.net>,
>  Gregory Ewing <greg.ewing at canterbury.ac.nz> wrote:
> 
>> Roy Smith wrote:
>> >>If both are numbers, they are converted to a common type. Otherwise,
>> >>objects of different types always compare unequal
>> 
>> That's just the default treatment for unrelated types that don't know
>> anything about each other.
>> 
>> I would guess that the list's == method is asking "Is the other object
>> a list?", and since a subclass of list is also a list, it's happy and
>> goes on to compare the elements.
> 
> Well, that explains what's happening, but the behavior still doesn't
> match the docs.  Is this a bug or are the docs wrong?


The docs are incomplete.

You are missing two facts:

* The docs you are quoting refer only to built-in types. That it doesn't 
make so clear is a documentation bug.

* Talking about "different" and "same" types is ambiguous. It depends on 
how you compare types:

type(a) is type(b)

isinstance(a, type(b))

You are reading the docs as if the first comparison is the way to do it, 
but the second is usually preferred.

Any time you read something about "the same type", you should mentally 
add "(or an instance of a sub-class)" to it, unless explicitly told 
different. Whether it is better to add that parenthetical comment every 
time it is needed, or to assume that the read knows enough about object-
oriented programming to assume it, is an open question.

Me personally, I think it's part of the mental landscape that can be 
assumed, like C docs might state "dereference the pointer" without adding 
"(unless it is a nul pointer)" *every single time*.


-- 
Steven



More information about the Python-list mailing list