assignment to __class__ (was Re: Copy constructors)

[Peter Hansen]

Alex Martelli wrote:
> 
> So, if protecting "typical users" against their own mistakes
> is a priority, it seems that Java fills that niche 'better'
> than Python does.
> 
> So where's Python's strength?  In *NOT* going as far as Java
> in this 'protection' racket (notoriously a lucrative one, but
> shady:-) -- in *selectively* protecting against stuff that's
> worth protecting against, but no more than that -- and thus
> not *getting in the way* the way Java does.

Hear hear!  I have a bevy of "typical" Python programmers
(lets say that means fairly new to Python, not new to
programming, but in any event they all have brains,
as most "typical" Python programmers do :)  and I have 
*not* felt the slightest need to protect them from 
themselves.  In fact, my choice of Python for this
team versus something like Java is based largely on 
the lack of implicit protection and the on the default 
dynamicism which Python provides, perhaps almost as much 
as it is on Python's vaunted readability.

> The keywords from my POV in the sentence
> "optional explicit stopping of dynamic behavior" are:
>     1. most important: OPTIONAL -- there must still be
>        a way to get the good old dynamic behavior
>     2. very important: EXPLICIT -- ideally, dynamic
>        behavior should be the default, with a way to
>        EXPLICITLY turn it off, rather than vice-versa
> 
> "Optional, explicit stopping" would mean a smooth progress
> towards a Greater And Better Python.  Changing defaults,
> or, worse, removing some of today's dynamic aspects, even
> though they had "just slipped in by mistake", has darker
> characteristics... 

I agree completely that this change, ostensibly being
made (a) to protect "typical" programmers, and (b) to
make Python faster, should be made in such a way that
is is both optional and not the default.

No "typical" programmer uses this feature anyway.  Nor
would one accidentally bump into it and need to be 
protected from doing so, even if it were really a 
good thing to protect typical Python programmers.

As far as optimizing/tuning performance, I think the
best points made on this subject have been (a) Python
can't possibly compete with many other languages and
shouldn't feel the need to and (b) make it an _option_
to select better performance, the same way it is an
option even to try optimizing one's code.  Don't try to 
push optimized Python down my throat; I'm quite happy
having an option to improve performance, which I 
can choose not to exercise (or ignore without risk).

I should be able to say, after everything is working
and I'm long past the point of needing some dynamicism,
hmmm, this part of my code clearly will never need
this dynamicism, _and_ it needs to run faster, so I'm 
going to disable that capacity, to improve performance.
Please don't make it so I have to think, for *all* the
code I write, about whether or not I will ever need this 
feature: you'll just slow me down.

-- 
----------------------
Peter Hansen, P.Eng.
peter at engcorp.com