Copy constructors

[Christian Tanzer]

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

> Glyph Lefkowitz <glyph at twistedmatrix.com> writes:
> 
> > Am I correct in understanding from this thread that there is an intent to
> > remove the ability to assign an instance's __class__ attribute?
> 
> Yes, I'd like to remove this.  See my previous post in this thread for
> more of an explanation of the problem.  But I haven't decided yet!
> This thread will help me figure out how big of a deal it will be.
> 
> Also note that nothing will change (yet) for classic classes -- in
> 2.2, classic classes will use a different metaclass from "new-style"
> classes, and the classic metaclass will provide the same semantics
> for classes and instance as before.  The class statement creates a
> classic class by default -- unless you explicitly subclass from a
> built-in type or a new-style class.

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?

> > One
> > of the eye-popping cool features of Python is the ability to change code
> > and have existing instances update to use the new methods automatically.
> 
> You will still be able to modify *classes* dynamically -- although you
> have to declare this option by putting __dynamic__ = 1 in your class
> statement.

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.

Dynamicity is one of the really strong points of Python -- eye popping
as Glyph just called it.

> > I don't know about others who use this feature, but the way I use it I
> > could afford to wait 0.5 seconds for each __class__ assignment and not be
> > too upset about it.  Losing this ability entirely, however, would remove a
> > significant feature from Twisted when used with a later python version.  
> > I implore you not to remove it.
> 
> 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. 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.

> I guess I have a bit of a hidden agenda: Python is more dynamic than
> the language I *wanted* to design.  Some of the dynamicism was simply
> a implementation trick.  Some of the dynamicism is getting in the way
> of optimizing code, because the optimizer can never prove that certain
> variables won't be changed.  So I'm trying to look for ways that pin
> down things a bit more.  I'm making assumptions about how "typical"
> Python code uses the dynamic features, and I'm slowly trying to
> introduce restrictions in the language that make the optimizer's life
> easier without affecting "typical" code.

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

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>

> For example, we're looking into optimizing access to builtins.  For
> this, we need to assume that the __builtin__ module is immutable; in
> addition, if a module doesn't have a global 'len', for example, we
> have to assume that such a global won't be inserted into the module
> dynamically.  I'm only aware of a very small number of applications
> that violate this constraint; I'd rather provide a separate explicit
> mechanism to override built-in functions so that the optimizer can be
> aware of a potential change and avoid it.

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.

Maybe module objects could even grow `get-set` magic in the process
<duck>. 

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