Guido van Rossum
guido at python.org
Sat Aug 11 15:06:57 CEST 2001
"Alex Martelli" <aleaxit at yahoo.com> writes:
> "Guido van Rossum" <guido at python.org> wrote in message
> news:cp66bv46jk.fsf at cj20424-a.reston1.va.home.com...
> > While I probably introduced this myself (pickle uses it), I have one
> > reservation. Assignment to self.__class__ is unique to Python -- it's
> > not an idiom one can easily translate to other languages. It's also a
> > relatively new Python feature (I don't even know if Jython supports
> I believe Ruby and Perl both have the powerful (if rarely used)
> "change class dynamically" feature. It would be a pity if Python,
> which introduced it, were now to lose it. A similar feature was a
> *hair-breadth away* from making it into early C++, according
> to Stroustrup's "Design and evolution" book -- he seriously
> considered the possibility of an object referring to its own
> 'base-object' via a pointer (as is done in virtual inheritance)
> with the ability to change that pointer in the fly (leading to a
> recomputation of virtual tables) -- he eventually gave it up,
> with some regrets, for performance considerations (possibility
> of 100%-performance being always a high priority in C++'s
> evolution -- specifically, zero mandatory overhead being imposed
> on code _not_ using some advanced feature).
> I call the feature 'rarely used', but others may use it less
> rarely. Moshe Zadka, for example, has advocated that a
> class-change is the right way to 'customize' a specific
> instance, rather than adding a method to the instance itself
> on the fly (I'm not quite sure why, and wouldn't want to
> misrepresent his position, but I believe it has to do with a
> wish to see behavior as associated with _classes_, not with
Let's just say that use of this feature is at your own risk. It was
an experiment. I *could* restore it partially (see below) but I'd
rather not, given that better alternatives are available.
> > But maybe more importantly, I don't know how to support this esoteric
> > feature after the type/class unification is complete. Under the new
> > system, not all instances are born the same: instances may have slots
> > for instance variables rather than a __dict__ -- using slots makes for
> > more space-efficient instances. (Having a __dict__ is still the
> > default, and an instance can have both slots and a __dict__.)
> So presumably not just ANY class-object may be assigned as
> the __class__ attribute of a given instance: there will be a type
> error if the class and the instance don't agree on slots/dictionary
> use. Can't this be checked at runtime when some
> instance.__class__ = anewclass
> is attempted?
I'm sure I'd be able to come up with some kind of check that works.
It would probably be very similar to the check I already use to
determine whether two base classes are compatible -- the check that
stops you from doing "class C(list, dictionary)". But I repeat: I'd
> If this check slows down this specific esoteric
> feature this shouldn't be a problem.
That depends on how much of a slowdown it is. :) The start of this
thread was about avoiding work done by __init__.
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-list