Copy constructors

Guido van Rossum guido at
Sun Aug 12 03:39:58 CEST 2001

Glyph Lefkowitz <glyph at> writes:

> > I don't know of any better way to handle the Promise design pattern,
> > either.  In C++, I'm having to kludge around it all the time via
> > letter/envelope idioms -- the possibility of changing classes on the
> > fly makes it much simpler and more direct.  Hadn't thought of that
> > earlier...
> I think the ZODB uses something like this, but it's implemented using
> ExtensionClasses.  I'd hate to see it become a requirement to muck around
> in native code.

Note: an explicit goal of the typeclass unification is that it should
become a *better* mechanism than ExtensionClasses, and eventually Zope
will be rewritten to use the new mechanisms.  We expect that this
solution will actually be cleaner than the existing Zope

So if you're relying on something that Zope needs to do, rest assured,
we'll find a way to do it under the new system too!

> > That one seems to be related to _another_ capability (of which I've
> > seen no indication that it's also going away) -- keeping the same
> > class object. but changing that object (rebinding method attributes
> > thereof).  Or maybe I don't understand exactly what you mean?

As I just wrote, there will be two kinds of classes: immutable
(static) classes and dynamic classes.  The latter can be modified just
like classic ones.  But since this makes them less efficient, you have
to be explicit about this (when using the new class mechanism, which
is not the default in 2.2).

> Hmm, I suppose that could be done as well; I'd have to do some other
> shuffling around of class references in order to keep isinstance() working
> like it should, but you're right: it's not impossible.
> > It seems to me the functionality of become is homomorphic to that
> > of class-assignment, unless I'm truly missing something major.
> Class-assignment + dict-assignment is nearly homomorphic. Of course, if we
> could do *real* reference replacement, then you could have a Promise for a
> python list :-).

What do you mean by "real reference replacement"?

--Guido van Rossum (home page:

More information about the Python-list mailing list