Using property in classic class may not work

[Bengt Richter]

On Tue, 15 Apr 2003 14:40:13 GMT, Alex Martelli <aleax at aleax.it> wrote:

>A. Lloyd Flanagan wrote:
>
>> Alex Martelli <aleax at aleax.it> wrote in message
>> news:<ifPma.15344$LB6.409776 at news1.tin.it>...
>>> Neil Hodgson wrote:
>>> 
>>> >     The class in question is derived from a wxWindows class, so I can't
>>> > make it derive just from object. The "What's New in Python 2.2"
>>> > document only mentions property wrt new-style clases. Can I depend on
>>> > property working for classic classes? Is there a workaround such as
>>> > deriving from object as well?
>>> 
>>> No, and yes, respectively -- deriving from object means your class
>>> isn't classic any more, so properties do work as intended there.  Vide:
>>> 
>> ... (big chunck cut) ...
>>> as you see, this does work as intended.
>>> 
>>> 
>>> Alex
>> 
>> However, the last time I tried to subclass from both wxFrame and
>> object, wxPython freaked out (that's a technical term for "I don't
>> remember what happened, but boy, it sure didn't work").
>> Not sure about the latest version of wxPython, though -- there's
>> binaries for python 2.3 out by now.  I'll have to try it again..
>
>If wxPython keeps freaking, you may have to give up on properties
>if you HAVE to inherit its classes (can't just wrap with automatic
>delegation) and go back to "good old" (yeah right) __setattr__.  Or,
>gently pressure wxPython's maintainers to have them move to
>new-style classes... whatever aspects of old-style classes they
>may be taking for granted at present, migrating to new-style can
>hardly be a major job, in my experience.
>
>
I may be fooling myself here, but a quick experiment suggests being
able to define a new class that inherits from both a classic class
that you can't touch and a new-style one that you can give a property, e.g.:

 Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32
 Type "help", "copyright", "credits" or "license" for more information.
 >>> class Old3rdParty:
 ...     def oldMethod(self): print 'oldMethod was called'
 ...
 >>> class NewPropertyCarrier(object):
 ...     def __init__(self, v): self.prop = v
 ...     def _get_p(self): return self._v
 ...     def _set_p(self, v): self._v = v
 ...     prop = property(_get_p, _set_p)
 ...
 >>> class Derived(Old3rdParty, NewPropertyCarrier):
 ...     pass
 ...
 >>> d = Derived(123)
 >>> d
 <__main__.Derived object at 0x007D68E0>
 >>> d.prop
 123
 >>> d.oldMethod()
 oldMethod was called
 >>> d.prop = 456
 >>> d.prop
 456

It seems like prop is surviving as a property, not getting clobbered into an attribute:

 >>> dir(d)
 ['__class__', '__delattr__', '__dict__', '__doc__', '__getattribute__', '__hash__', '__init__',
 '__module__', '__new__', '__reduce__', '__repr__', '__setattr__', '__str__', '__weakref__', '_ge
 t_p', '_set_p', '_v', 'oldMethod', 'prop']
 >>> vars(d)
 {'_v': 456}
 >>> d._v
 456
 >>> d.prop
 456
 >>> d._v = 'sneaky'
 >>> d.prop
 'sneaky'
 >>> d.prop = 'normal'
 >>> d.prop
 'normal'
 >>> d._v
 'normal'

So could wxPython play the role of Old3rdParty above and allow building a Derived with
the properties desired? Or is mixed bases a no-no?

Regards,
Bengt Richter