Copy constructors

[Christian Reis]

Guido van Rossum <guido at python.org> wrote in message news:<cpzo969i4k.fsf at cj20424-a.reston1.va.home.com>...
> 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.

I can present a different use-case so the decision can take these
things into account. I've written a set of wrappers for the basic GTK
widgets, and they're done in pure Python. Now Gtk has a companion
library called libglade which can query an XML file and retrieve
widget definitions, which it then instantiates and returns into
Pythonland through a libglade.py module. The libglade C module does
some fancy work with the widgets, and in the end they show up as
regular Python GTK instances. However, because I want them to be
"cast" into my wrappers, I just swap attribute my wrapper class to the
instances' __class__ attributes. This is, AFAICS, the only solution
without modifying the C module or re-wrapping the Python code.

This is a very valuable ability in python, and I'd very much like to
know, in the case it won't be preserved, if something functionally
equivalent could be proposed as a future addition.

> But you're getting so much in return!  Subclassing built-in types,
> get/set methods, class and static methods, uniform introspection...

Yep, these are valuable. But it's tough giving up something nice
you've grown fond of :)

> If you know the type it's going to be eventually, you can use
> C.__new__() to create an uninitialized C instance.

This doesn't help in my case, unfortunately. :/

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL