Copy constructors

[Guido van Rossum]

[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.  It would
be somewhat difficult if you wanted to make sure that abuse couldn't
lead to core dumps, because you'd have to implement a hairy check
(which I haven't figured out yet but which I believe is possible in
principle) that determines whether the old and the new __class__ have
compatible instance structure.

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

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

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

> OTOH, this tiny percentage might itself be used by a lot of other
> code. At least in my applications some modules do make use of some
> eye-popping features and they tend to be used all over the place.

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

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

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

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

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

--Guido van Rossum (home page: http://www.python.org/~guido/)