kiko at async.com.br
Sat Aug 18 16:50:50 CEST 2001
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. :/
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL
More information about the Python-list