Copy constructors

[Guido van Rossum]

[me]
> >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__.)

[Roman Suzi]

> Couldn't slots just be mapped to __dict__ in case somebody accesses it?
> Will __dict__ reflect available slots?

I wasn't clear.  It's not about whether or not something called
__dict__ is visible.  It's about whether the object lay-out of the old
and new class are compatible.

> I know that Python docs never guarateed __dict__ to be the same forever,
> but it is used in classes to do attribute assignments in __setattr__ and
> similar circumstances...

Incidentally, the new system doesn't require manipulating __dict__ for
this purpose.  First of all, you can use "getset attributes" to trap
specific attributes (see http://www.python.org/2.2/descrintro.html).
Second, a typical __getattr__ override can now use object.__getattr__
to access the default implementation.  This is important given that
you don't always have a __dict__. :)

> Then slots are statically-named attributes (if I understood correctly).
> Maybe it will be honest to give some kind of __attrlist__ attribute which
> will be similar to __dict__ but devoted to those static slots?

Static slots are described by class attributes.  Read PEP 252.

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