Home Original page

Copy constructors

Alex Martelli aleaxit at yahoo.com
Mon Aug 13 02:56:22 EDT 2001 
"Aahz Maruch" <aahz at panix.com> wrote in message
news:9l7kq5$6fn$1 at panix2.panix.com...
> In article <9l5h650j8o at enews4.newsguy.com>,
> Alex Martelli <aleaxit at yahoo.com> wrote:
> >
> >"Premature optimization is the root of all evil" (Kernighan, I believe).
>
> Knuth.
>
> In return for this little correction, would you please explain in simple
> words exactly what it is that you're talking about?  I'm reasonably
> adept at understanding plain classes, but you've been going way over my
> head here.  I suspect other readers of c.l.py would like to understand,

I had posted a simple solution to a problem "how do I build an _empty_
object of some class bypassing the class's __init__ (which does a lot of
work) so I can then manually copy the relevant parts of the state":

def empty_copy(object):
    class Temp: pass
    result = Temp()
    result.__class__ = object.__class__
    return result

Guido explained that this would not work any more in 2.2 or a bit later,
because the assignment to result.__class__ would be eventually
disallowed.  Now, this is not a big problem for this particular case: not
only will there be a new class special method called __new__ that makes
an empty instance, but even today there are workable alternatives, such
as "return new.instance(object.__class__)" (it has not been discussed
what happens to module new in 2.2 and later, but it's a rather "deep
internals" module, so nobody will be surprised if it changes).  However,
there are other use-cases for "changing the __class__ of instance x" --
none used very frequently, but, some of us believe, rather a significant
Python feature (Guido isn't very convinced of the latter point).

In the ensuing discussion, another related issue emerged.  Today, a
Python class is a mutable object; if and when you need to change it,
it's as easy as changing any other object -- and all instances of the
class are implicitly "updated" when the class object is.  This is not
used very often, either, but the fact that any class object CAN be so
updated is also significant: it may be used to fix a running program
with new code without huge investment in infrastructure as would be
needed to perform similar tasks in a less-dynamic language.

However, some classes will be unchangeable in 2.2 and/or later, and
Guido plans to make unchangeability the *default*, requiring users
to explicitly set class attribute __dynamic__ to 1 to make a class
changeable (there may be some help: the default __dynamic__ for
classes in a module may be a module attribute, and a class may
inherit it from ancestors).  Having optimization as the default, with
dynamicity a special-case requiring explicit request, feels like more
of a C++ attitude than a Python one to several of us (although there
are Pythonic precedents, such as local variables of a function).  Such
an optimization may be deemed "way-premature", as it occurs at
language-design time:-).  If dynamism is used to fix potential bugs
in a running server, for example, it's hard to see how the user may
be required to predict in advance which classes he's writing have
bugs and thus may need to be updated on the fly.  Having the
possibility of turning class changeability explicitly *off* sounds like
a great optimization -- but, some of us feel, it should be the
general case that's the default, optimization working when explicitly
requested, rather than vice versa.  (I.e., NOT as in C++'s "virtual"
for methods and repeated inheritance, which many, though not all,
think of as a C++ misfeature).

Guido's counter-argument is that classes that need to be dynamic
will emerge in testing, while having dynamism as the default might
lead to it being used wantonly and making later optimization hard.
On this issue as well as unchangeability of __class__, he seems to
be very motivated towards performance/optimization possibilities,
which may explain the eerie C++ parallels (performance was always
paramount in C++'s design, while, so far, it doesn't seem to have
had all that strong an influence on Python).

He may be right, of course (he generally is) -- perhaps we've all
grown used to a Python that's in good part defined by dynamic
possibilities that "just happened" to fall out of implementation
techniques and were never a design-intent (if somebody knows
the design-intent, it should be him:-), and giving up on those
will have a general benefit in terms of performance increase.  I
still believe that when I need performance I code or recode in
C++, or in C, and I'd like Python to stay simple and wonderful.
But many (particularly those who have not exploited the dynamic
possibilities, are not familiar with C++, etc) may agree with Guido.

It will surely be a very different language when this type/class
unification thing gets finished...!


Alex
More information about the Python-list mailing list