Copy constructors

[Guido van Rossum]

"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
> _instances_).

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
rather not.

> 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/)