Copy constructors

[Christian Tanzer]

Guido van Rossum <guido at python.org> wrote:

> > 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 read that and was not convinced. I'll try to explain why.

Unless one has a time machine, the most important property of a
program is being able to evolve. Lack of evolvability means its hard
to fix bugs, its hard to refactor to improve reusability, its harder
to satisfy new requirements...

As one can't know which part(s) of a program will need to be changed,
its best to try to keep them all changeable. One means to do that is
to do bindings as late as possible and to allow rebindings at
run-time. This hurts performance wise but results in better software.
As most of the code won't be performance critical anyway the
performance hit might be negligable and it should be easy to optimize
the hot spots by making them less dynamic if necessary. 

The current dynamicism of Python allows late bindings and even
rebindings at run-time. Just one example where Python really saved my
day: a customer uses a frozen Python program. After a while, he
decides that he wants something done slightly differently. Even if I
think the request unreasonable I can easily send him a tiny script
which changes one method in the frozen application to do what the
customer wants. With no dynamicism as default this wouldn't be
possible. Of course, I could have created a customer-specific version
of the application -- the effort would have been days instead of
twenty minutes plus an extra branch in the code (instant killer of any 
such proposal). 

There is yet another aspect to this. If a language forces you to
choose between performance and flexibility at design-time it eases the
work of the language implementer but at the same time makes the life
of all language users much more difficult. If you want to keep your
code flexible and/or reusable you forgo performance -- the language
will not try to optimize the flexible code. If you decide to choose
performance, later changes might be much more difficult and on top end
up with poor performance.

> > 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.

:-)

> > 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).

IMO, those aren't really contenders (certainly not Lisp [for me]).
Python is just the right thing: simple, readable, maintainable,
dynamic. (And the dynamicism can help to make the code more
maintainable). 

> Most people like Python
> because it's so darn readable and maintainable.  Unbridled dynamicism
> goes against that. I am striving for a balance that allows most forms
> of dynamicism, but requires a declaration in advanced for the more
> extreme kinds.

Agreed.

> > Maybe module objects could even grow `get-set` magic in the process
> > <duck>.
> 
> You probably don't realize it, but you can write modules with get/set
> magic now, by stuffing an instance in sys.modules[__name__].

Maybe the intended <wink> was too implicit in my mail?

I knew about putting instances into the module dictionary -- somebody
borught that up on c.l.py. a few months ago. As this is not a
documented feature (IIRC), I would have been worried about using it,
though.

Hope-this-didn't-add-to-the-flames, y'rs

-- 
Christian Tanzer                                         tanzer at swing.co.at
Glasauergasse 32                                       Tel: +43 1 876 62 36
A-1130 Vienna, Austria                                 Fax: +43 1 877 66 92