Copy constructors

[Glyph Lefkowitz]

On Sun, 12 Aug 2001, Alex Martelli wrote:

> > A dynamic class will be slower than a static class, so I prefer having
> > to request this explicitly.  But we can certainly quibble about that!
> 
> As I said, exactly Stroustrup's reasoning in C++'s design -- a non
> overridable method is faster than a virtual one, so he preferred to
> make users request virtuality explicitly.  Like anybody who's ever
> taught C++ or helped beginners in that language fix mistakes, I've
> had occasion to bemoan that design choice repeatedly -- even though,
> with performance such an important priority for C++, and historical
> compatibility reasons, it's quite understandable.  It appears to me
> making static classes the default is a similar choice, requiring lots of
> up-front design (dynamic classes are used to change behavior of
> a running program, for example -- to refactor, unless dynamic
> classes have been specified beforehand for all important places,
> the program needs to be stopped), facilitating premature optimization,
> and without Stroustrup's particular excuses (surely performance is not
> as key a criterion for Python as for C++, and in this case we'd be
> going _against_ historical compatibility).

Let me underscore this once, and put it in the terms I think of it in:
with these changes, you will be introducing the worst design error of C++
into Python.  Indeed, the _central_ problem with C++ is that it always
prefers efficiency over dynamism, even in its so-called "high level"
features.

If python were not as dynamic as it is, it would be _completely_
uninteresting to me; especially given that these changes are not going to
propel python into the running as even a mildly fast programming language
(do you believe that you can approach the performance of HotSpot or GCJ by
making classes static?  The speed of the VM for Squeak with its JIT and
massively optimized GC?).  Features like class assignment constitute not
only a convenience for me, but in many ways a near religious experience
about how important making one's code dynamic is.

(I tried to think of a nicer way to say this; and I apologise in advance
for failing to do so, but...) This exchange confirms my suspicion, that
I'd seen voiced once before on this mailing list, that Guido doesn't
really know what it is that makes Python cool.  To me, it's obvious that
the _point_ of the whole thing is dynamicism; of course, as Travis
Hartwell said of Twisted, "... it seems like you guys program a different
Python than I do. You use its dynamic nature and all of that so much more
than I have ever thought of."  Maybe it's only a matter of time before we
really _are_ using a different language. :-(

> > I expect that the new facilities will be seriously user-tested only
> > after 2.2 is released, and experience will learn how often people are
> > changing class variables.
> 
> You think people will be changing class variables _less_ often than
> now because of 2.2's new facilities?  I don't see the relevance, but I
> guess I must have missed something.  The new facilities appear to be
> very deep and important, but in areas quite different from those in
> which class-object changes are useful, it seems to me.

It is an act of supreme arrogance -- which all programmers commit, on
frequent occasions, myself included -- to assume that the users of your
code will not want to change it.  Slightly less arrogant, but perhaps more
annoying, is the assumption that the users of your code will not want to
change it at run-time.  Every time I have made this assumption, I have
been wrong.  (Even when I was the only "client" of my code! ^_^)  
Sometimes that wrongness is worth paying for, because of size or speed
considerations -- but that event is sufficiently rare that I'd much rather
have to explicitly say "__be_fast_not_nice__ = 1".

I've heard it said that the art of software engineering is the art of
deferring binding until later and later.  Python defers it as long as
possible, with really excellent results.  To make it do so any sooner
would be to make it less artful :-)

                      ______      __   __  _____  _     _
                     |  ____ |      \_/   |_____] |_____|
                     |_____| |_____  |    |       |     |
                     @ t w i s t e d m a t r i x  . c o m
                     http://twistedmatrix.com/users/glyph