Copy constructors

[Glyph Lefkowitz]

On Mon, 13 Aug 2001, Guido van Rossum wrote:

> [Christian Tanzer]
> > Would it be possible to possible to write a meta-class allowing the
> > dynamic change of __class__? And if so, how difficult would that be?
> 
> That would be possible if you're willing to write it in C.

I thought we said that things were going to get _better_ than
ExtensionClass, not worse?

> > I'd like to support the proposal of Glyph and Alex to make 0 the
> > default for `__dynamic__`. IMHO, optimization should be restricted to
> > those few modules where it is really necessary.
> 
> See my response earlier in this thread.

I've read several responses and none of them are really acceptable.

> > Dynamicity is one of the really strong points of Python -- eye popping
> > as Glyph just called it.
> 
> Eye popping can be a negative point too.  I'd prefer a warning before
> my eyes are popped.

If _you_ get a 'warning', _I_ can't do eye-popping things with your code.  
Then python becomes just like Java but slower, for me.

> > > Understood.  Nevertheless, all evidence suggests that Twisted is not
> > > typical Python code. :-)
> > 
> > What is typical? I'd assume that a tiny percentage of Python code uses
> > the really dynamic features.
> 
> Tiny indeed.

A tiny percentage of Python code uses division, (FWIW, I use dynamic
features a lot more than division) but we've seen the furor over _that_
one for months.  A "tiny percentage of python code" also probably takes up
90% of the execution time of "typical" python programs.

> Because __dynamic__ is inherited, if you inherit from an eye-popping
> class, your class will automatically be eye-popping too.

Every class in twisted will then have to inherit from twisted.base.Object
in order to circumvent this silliness.  (That in itself makes it remind me
of C++; when the first thing I'll do on a project is import
workarounds_for_language_design_errors.) But we still won't be able to
assign to __class__...

> > Please be careful in this crusade... The language you *wanted* to design
> > might have been not quite as
> > excellent/wonderful/<insert-your-favorite-exclamation-of-insane-
> > greatness-here> as the one you came up instead :-) 
> 
> Please trust me...  The changes I have in mind might not be so
> devastating for Python's beauty as you seem to be thinking. :-)

Sorry, Guido, but my trust for you goes about as far as I believe the
features of Python I like were intentional.  In this thread, you're
talking about breaking or perverting quite a few of them.  I'm just
waiting for the other shoe to drop and you to decide we really need
variable declarations and braces.

I have a great deal of respect for you and I thank you for giving us
Python, but I am serious when I say that you should develop this new
non-python language elsewhere; it sounds like your (surprising and new?)
design aims are contrary to what many of us are using python for in the
first place.

> > I wouldn't mind if I had to ask for some dynamic features more
> > explicitly than now but I'd really be hard hit if they went away
> > entirely. I'd love to get better performance but not at the price of
> > loosing all this dynamicism. I if wanted to use a non-dynamic language
> > I'd know way too many candidates vying to make my life unhappy <0.1
> > wink>
> 
> Some people like Python for its extreme dynamicism.  But there are
> other languages in that niche (like Lisp).

Yes.  And many lispers have come to Python because of the similiarities.  
Python has a better, more standard, more friendly implementation than most
lisps.  If there were a good, free, UNIX-friendly lisp implementation with
good support for AIO or microthreads, I would not be using Python right
now... except for the fact that it's much _more_ dynamic than lisp.

Consider:

 * lisp is far more efficient than python can ever hope to be, at least in
   its good implementations (Franz cites numbers that exceed the speed of
   "typical" C++ code; its design is such that it's easier to optimize

 * lisp has a better defined object model than Python does

 * lisp has a dynamic reader.  I could (and will, when I start using
   lisp regularly) implement a Python-like syntax in the space of a few
   days.

 * lisp has macros, where python doesn't.

 * lisp can really treat code as an object, making metaprogramming and
   certain kinds of system architecture much more feasible.

Why would anyone in their right mind use python instead of lisp?  Well,
it's super-dynamic.  It has a large and friendly (if somewhat ad-hoc)
standard library.  It plays nice with UNIX as well as Windows.  It has
sane and comprehensible FFI.  The implementation is unified, well-tested,
and cheap.

If you take away reason #1, then a lot of Lisp's features can compensate
for the other implementation issues, and issues like "no macros" and
"static syntax" become instantly crippling instead of mildly
inconvenient... *ESPECIALLY* if you take away reason #1 when it was
already working fine, and there is no indication (as far as I can tell)
that anyone else is unhappy with this state of affairs!

The one thing that Python will have is "consistent syntax and
implementation strategy", but that's a mostly a cultural issue, not a
technical one.  Adding macros as the way of doing things rather than
dynamicism would be more efficient, but less conducive to python's
excellent culture :-D.

> Most people like Python because it's so darn readable and
> maintainable.  Unbridled dynamicism goes against that.

This is of course the reason why C++ and Java programs are so much easier
to debug than python.  All those spelling errors on attribute names -- and
the compiler can't even check them for you!  Sheesh.  Good thing that
python's at least more efficient than those static languages, or there'd
be no reason to use it. :-P

> I am striving for a balance that allows most forms of dynamicism, but
> requires a declaration in advanced for the more extreme kinds.

Personal experience leads me to believe that the more extreme your
dynamicism, the more problems you can worm your way out of down the line,
and the more "bridled" it is, the easier it is to become locked into a
particularly bad design decision.

The excellent thing about python's dynamic nature, much like the excellent
thing about its syntax, is that it's _always_ there.  I can _always_
assign to the __class__ of an instance, always stick in a __getattr__ of
its class that does what I want; always poke __del__ so that I can track
garbage collection *even if it's not my code*.  (have I emphasized this
enough yet?  Sometimes there are bugs in code written by programmers who
are _not_ me! ^_^)  Yes, it would be more efficient to not do so; yes, it
would be more flexible if we made the syntax dynamic, or added macros.  
This kind of efficiency or flexibility would make python worse for me (and
I see this sentiment echoed by everyone else who's posted to this thread.  
Does anyone agree with guido?  Tim? ^_^)

> > Separate explicit mechanisms would be much better than just dropping
> > dynamicism. In fact, despite the need for changing working code
> > <sigh>, making an external change of a module explicit would probably
> > be a good thing.
> 
> Exactly.  I'm not planning to drop dynamicism -- I'm planning to make
> it more explicit.

Making an external change of a module variable or class variable already
_is_ explicit.

  import foo; foo.bar = baz

  class Foo: pass
  Foo.x = 1

What's implicit about either of these things?

the-dutch-might-be-blunt-but-nobody-ever-accused-them-
	of-being-obvious-or-even-comprehensible-ly y'rs,

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