2.2 features

Guido van Rossum guido at python.org
Tue Jul 31 09:01:43 CEST 2001

Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> writes:

> If you forget about 'isinstance' then everything is ok, right?
> 'in' performs some membership test whose details depend on the second
> argument. It should not be more confusing that '+' being either addition
> of numbers and concatenation of sequences. We don't expect "a"-(-"b")
> to be equivalent to "a"+"b" just because 3-(-4) is equivalent to 3+4.
> Now thow in 'isinstance' as an old way to spell a specific membership
> test (for types and classes) which doesn't have to be learned about
> at all.

I love it.  'x in type' as a shorthand for isinstance(x, type).
Checked into CVS!

> > Or you could just say that type objects implement a __contains__
> > method that does an isinstance. But if classes and types are unified,
> > that would get in the way of classes that define __contains__.
> It indeed shows a flaw in unifying "attributes of instances which
> are defined by their classes" with "attributes of class objects
> themselves".
> For example many objects are hashed by what o.__hash__() returns,
> but not type objects, because their __hash__ is something completely
> different (it expects an argument and hashes it instead of the
> receiver). Similarly for most magic methods.
> It more or less works because intersection of proper attributes of
> type objects and attributes which are always polymorphically extracted
> using names (and not slots in the representation of type objects)
> happens to be empty.
> This is so hardwired into Python and pushed by type/class unification
> that I don't believe it can be avoided without redesigning the language
> from scratch.
> This particular case of __contains__ is not different than e.g.
> __hash__ or __str__. You can't redefine in Python how your class object
> (or type object in Python-2.2) will be hashed or printed, you won't
> be able to override the membership test either (and you can't now
> AFAIK) - unless something solves the generic problem of putting class
> attributes and static instance attributes in one namespace.

Good analysis of this particular problem, and indeed I've given up on
fixing it.

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-list mailing list