Copy constructors

[Robin Becker]

In article <9l7tm10rt at enews2.newsguy.com>, Alex Martelli
<aleaxit at yahoo.com> writes
>Guido's counter-argument is that classes that need to be dynamic
>will emerge in testing, while having dynamism as the default might
>lead to it being used wantonly and making later optimization hard.
>On this issue as well as unchangeability of __class__, he seems to
>be very motivated towards performance/optimization possibilities,
>which may explain the eerie C++ parallels (performance was always
>paramount in C++'s design, while, so far, it doesn't seem to have
>had all that strong an influence on Python).
>
>He may be right, of course (he generally is) -- perhaps we've all
>grown used to a Python that's in good part defined by dynamic
>possibilities that "just happened" to fall out of implementation
>techniques and were never a design-intent (if somebody knows
>the design-intent, it should be him:-), and giving up on those
>will have a general benefit in terms of performance increase.  I
>still believe that when I need performance I code or recode in
>C++, or in C, and I'd like Python to stay simple and wonderful.
>But many (particularly those who have not exploited the dynamic
>possibilities, are not familiar with C++, etc) may agree with Guido.
>
>It will surely be a very different language when this type/class
>unification thing gets finished...!
>
>
>Alex
>
I'm with Alex on this. Many of the latest changes seem to be in the
direction of making Python less and less dynamic in favour of speed or
regularity. I believe Python should be more dynamic not less.

The unification was supposed to bring the types into the class world.
This thread seems to indicate classes being made more like types.

The problem with dynamic not being the default is that the requirement
for dynamic behaviour is not very obvious.

If this class assignment is disallowed what about messing with __bases__
as in the injective/mixin methodologies?
-- 
Robin Becker