This is more of a Python issue than one specifically about wxPython, but it broke something in my code that worked prior to wxPython using new-style classes, so the issue might come up for someone else as well. Anyway, the issue is the difference between the built-in dict type and the dictproxy class. I couldn't find anything about dictproxy except via epydoc.
http://epydoc.sourceforge.net/stdlib/public/types.dictproxy-class.html
Compare to dict.
http://epydoc.sourceforge.net/stdlib/public/builtin.dict-class.html
As you can see, dictproxy doesn't have a __setitem__ method. All wxPython class __dict__ are dictproxy instances, so my code where I was doing:
self.__class__.__dict__[aMethod.__name__] = aMethod
to dynamically add a method to a class at runtime won't work anymore because dictproxy is missing __setitem__. Now, it is just as well that this old code doesn't work because I probably should have been using setattr all along.
setattr(self.__class__, aMethod.__name__, aMethod)
Anyway, that's my "guts of Python" lesson for today <wink> If there is more to this issue then let me know.
ka
dictproxy is a built-in type specifically designed to act as immutable as possible. Python classes are not prototypes and are not meant to be extended in this manner. Is it possible that you could replace this hack with subclassing? Why do you need to do this anyways?
-bob
···
On May 13, 2004, at 1:32 PM, Kevin Altis wrote:
This is more of a Python issue than one specifically about wxPython, but it broke something in my code that worked prior to wxPython using new-style classes, so the issue might come up for someone else as well. Anyway, the issue is the difference between the built-in dict type and the dictproxy class. I couldn't find anything about dictproxy except via epydoc.
http://epydoc.sourceforge.net/stdlib/public/types.dictproxy-class.html
Compare to dict.
http://epydoc.sourceforge.net/stdlib/public/__builtin__.dict-class.html
As you can see, dictproxy doesn't have a __setitem__ method. All wxPython class __dict__ are dictproxy instances, so my code where I was doing:
self.__class__.__dict__[aMethod.__name__] = aMethod
to dynamically add a method to a class at runtime won't work anymore because dictproxy is missing __setitem__. Now, it is just as well that this old code doesn't work because I probably should have been using setattr all along.
setattr(self.__class__, aMethod.__name__, aMethod)
Anyway, that's my "guts of Python" lesson for today <wink> If there is more to this issue then let me know.
setattr works fine, so I'm set. As the variable names allude to, I'm adding methods dynamically at runtime, in this case event handlers. This isn't a common use-case scenario, but is extremely useful when you need it.
ka
···
On May 14, 2004, at 10:08 AM, Bob Ippolito wrote:
On May 13, 2004, at 1:32 PM, Kevin Altis wrote:
This is more of a Python issue than one specifically about wxPython, but it broke something in my code that worked prior to wxPython using new-style classes, so the issue might come up for someone else as well. Anyway, the issue is the difference between the built-in dict type and the dictproxy class. I couldn't find anything about dictproxy except via epydoc.
http://epydoc.sourceforge.net/stdlib/public/types.dictproxy-class.html
Compare to dict.
http://epydoc.sourceforge.net/stdlib/public/__builtin__.dict-class.html
As you can see, dictproxy doesn't have a __setitem__ method. All wxPython class __dict__ are dictproxy instances, so my code where I was doing:
self.__class__.__dict__[aMethod.__name__] = aMethod
to dynamically add a method to a class at runtime won't work anymore because dictproxy is missing __setitem__. Now, it is just as well that this old code doesn't work because I probably should have been using setattr all along.
setattr(self.__class__, aMethod.__name__, aMethod)
Anyway, that's my "guts of Python" lesson for today <wink> If there is more to this issue then let me know.
dictproxy is a built-in type specifically designed to act as immutable as possible. Python classes are not prototypes and are not meant to be extended in this manner. Is it possible that you could replace this hack with subclassing? Why do you need to do this anyways?