Type emulation issues with new style classes

[Chris]

Is there any way to make the class Z behave the same way as class Y?

Chris

class Y:
value = 42
def __hasattr__(self, name):
if name == '__int__':
return True
def __getattr__(self, name):
if name == '__int__':
return lambda: self.value

class Z(object):
value = 42
def __hasattr__(self, name):
if name == '__int__':
return True
def __getattr__(self, name):
if name == '__int__':
return lambda: self.value
TypeError: int() argument must be a string or a number

 

[Carmine Noviello]

class Z(object):
value = 42
def __hasattr__(self, name):
if name == '__int__':
return True
def __int__(self):
return self.value

Umm, maybe I haven't understood what you need.

 

[Chris]

I need to have Python call the the emulation methods for numbers, lists,
etc, when those methods are provided though __getattr__ rather than defined
in the instance or class __dict__. I've been up and down PEP 252 trying to
determine how Python determines the presence or absence of emulation methods
for new style classes, but I'm not having any luck.

class Z(object):
value = 42
def __hasattr__(self, name):
if name == '__int__':
return True
def __int__(self):
return self.value


Umm, maybe I haven't understood what you need.

I need to know how I can do what I previously demonstrated with an old style
class, that is hook into Python's introspection mechanism to dynamically
provide an __int__ method (or optionally __str__, __lt__, __le__, __eq__
,__ne__, __gt__, __ge__, __len__, __getitem__, __add__, __sub__, __mul__,
__floordiv__, __mod__, __divmod__, __pow__, __lshift__, ... ad nausuem).
Old style classes will let me do this, but I cannot determine how to do this
with new style classes.

Chris

 

[Aahz]

class Z(object):
value = 42
def __hasattr__(self, name):
if name == '__int__':
return True
def __getattr__(self, name):
if name == '__int__':
return lambda: self.value

IIRC, __getattribute__ may do what you want, but I don't have time to
check.

 

[Chris]

Tried it earlier, same result.

Chris

 

[Michael Hudson]

Is there any way to make the class Z behave the same way as class Y?

You need a custom metaclass for Z, and implement __getattr__ there.

HTH.

Cheers,
mwh

 

[Chris]

I tried a couple variation of that, and __getattr__, when defined in a
metaclass is never called when accessing an attribute on an instance of a
class derived from that metaclass.

Here is some testing I did:

class Zmeta(type):
def __getattribute__(*args):
raise Exception('called __getattribute__ with %s' % str(args))
def __getattr__(*args):
raise Exception('called __getattr__ with %s' % str(args))

Z = Zmeta('Z', (), {'value': 42})
z = Z()
Exception: called __getattribute__ with (<class '__main__.Z'>, '__int__')

It appears (and is confirmed in: Metaclass Programming in Python Pt. 2
http://www-106.ibm.com/developerworks/library/l-pymeta2/?ca=dnt-434) that
metaclass attributes are available to instances (classes) but not instances
of instances.

Chris

 

[Rainer Deyke]

class Z(object):
value = 42
def __hasattr__(self, name):
if name == '__int__':
return True
def __getattr__(self, name):
if name == '__int__':
return lambda: self.value

def __int__(self):
return self.__getattr__('__int__')()

 

[Greg Chapman]

class Z(object):
value = 42
def __hasattr__(self, name):
if name == '__int__':
return True
def __getattr__(self, name):
if name == '__int__':
return lambda: self.value

The following allows your test case to work, but it may have various subtle
problems. AddDynOper emulates __getattr__ semantics: the descriptor is not
installed if the type already has an attribute of the given name:

class DynOperDescr(object):
def __init__(self, name):
self.name = name
def __get__(self, instance, typ):
if instance is None:
return self
return instance.__getattr__(self.name)

def AddDynOper(declcls, name):
if not hasattr(declcls, name):
setattr(declcls, name, DynOperDescr(name))

class Z(object):
value = 42
def __getattr__(self, name):
if name == "__int__":
return lambda : self.value
raise AttributeError(name)
AddDynOper(Z, "__int__")

 

[Chris]

I'm looking for a way to do this without explicity definining every
emulation method, i.e. (__str__, __lt__, __le__, __eq__, __ne__, __gt__,
__ge__, __len__, __getitem__, __add__, __sub__, __mul__, __floordiv__,
__mod__, __divmod__, __pow__, __lshift__, ... ad nausuem). Plus, there's a
few this isn't going to work for several of the the arithmetic operators,
such as when I want to have __add__ undefined so Python will attpemt
__radd__. For example:

class Y:
value = 42
def __getattr__(self, name):
if name == '__coerce__':
raise AttributeError
if name == '__add__':
raise AttributeError
if name == '__radd__':
return lambda other: self.value + other.value
84

class Z(object):
value = 42
def __getattr__(self, name):
if name == '__add__':
raise AttributeError
if name == '__radd__':
return lambda other: Z.value + Z.value
if name == '__int__':
return lambda: self.value
def __int__(self):
return self.__getattr__('__int__')()
def __add__(self, other):
return self.__getattr__('__add__')()
def __radd__(self, other):
return self.__getattr__('__radd__')()

TypeError: 'NoneType' object is not callable

 

[Chris]

I tried your suggestion, but it breaks down when in the case where I want a
emulation method to be undefined. See example below.

Okay, it looks lke I'm going to have to come to the realization that there
is no way to hook into Python's test for the existance of emulation methods,
so I'm going to have to explicitly define every single possible emulation
method, from __add__ to __xor__. But still, how do I have __add__ return a
special value or throw a special exception so that the interpreter will then
move on to try __radd__?

### Works with old style classes ###
class Y:
value = 42
def __getattr__(self, name):
if name == '__coerce__':
raise AttributeError
if name == '__add__':
raise AttributeError
if name == '__int__':
return lambda: self.value
if name == '__radd__':
return lambda other: self.value + other.value
84


### With new style classes, __radd__ is never called ###
class DynOperDescr(object):
def __init__(self, name):
self.name = name
def __get__(self, instance, typ):
if instance is None:
return self
return instance.__getattr__(self.name)

def AddDynOper(declcls, name):
if not hasattr(declcls, name):
setattr(declcls, name, DynOperDescr(name))

class Z(object):
value = 42
def __getattr__(self, name):
if name == '__radd__':
return lambda other: Z.value + Z.value
if name == '__int__':
return lambda: self.value
raise AttributeError(name)

AddDynOper(Z, "__int__")
AddDynOper(Z, "__add__")
AddDynOper(Z, "__radd__")
AttributeError: __add__

 

[Rainer Deyke]

I'm looking for a way to do this without explicity definining every
emulation method, i.e. (__str__, __lt__, __le__, __eq__, __ne__,
__gt__, __ge__, __len__, __getitem__, __add__, __sub__, __mul__,
__floordiv__, __mod__, __divmod__, __pow__, __lshift__, ... ad
nausuem).

You can get away with mentioning all of those names only once in your code.

class IndirectionMixins(object):
pass

def add_indirection_method(name):
def f(self, *args, **kwargs):
return self.__getattr__(name)(*args, **kwargs)
setattr(IndirectionMixins, name, f)

for name in ['__str__', '__lt__', ...]:
add_indirection_method(name)

class Y(IndirectionMixins):
...

Plus, there's a few this isn't going to work for several
of the the arithmetic operators, such as when I want to have __add__
undefined so Python will attpemt __radd__.

That's harder. It might be possible with metaclasses.

 

[Michele Simionato]

I need to know how I can do what I previously demonstrated with an old style
class, that is hook into Python's introspection mechanism to dynamically
provide an __int__ method (or optionally __str__, __lt__, __le__, __eq__
,__ne__, __gt__, __ge__, __len__, __getitem__, __add__, __sub__, __mul__,
__floordiv__, __mod__, __divmod__, __pow__, __lshift__, ... ad nausuem).
Old style classes will let me do this, but I cannot determine how to do this
with new style classes.

Chris

You may want to look at this thread:

http://groups.google.it/groups?hl=i...=innermethods&meta=group%3Dcomp.lang.python.*

It does not solve your problem, but it may be of some interest.

Michele Simionato

 

[Michele Simionato]

I tried a couple variation of that, and __getattr__, when defined in a
metaclass is never called when accessing an attribute on an instance of a
class derived from that metaclass.

You may also look at this bug report:

http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=789262

The special lookup of special attributes has bitten at least three or four
person on this mailing list in the last year or so: I maintain that
it is a documentation bug.

Michele Simionato

 

[Chris]

That's my bug! That's exactly the problem I'm having. Thanks for the info,
it looks like I'll have to create a mixin class that manually defines all
emulation methods, but will be broken for __radd__, __rsub__, __rmul__,
etc... but as long as I make a note of it in the documentation, it should
be okay.

Thanks showing me the bug report.

Chris

 

[Michael Hudson]

I tried a couple variation of that, and __getattr__, when defined in a
metaclass is never called when accessing an attribute on an instance of a
class derived from that metaclass.

Here is some testing I did:

class Zmeta(type):
def __getattribute__(*args):
raise Exception('called __getattribute__ with %s' % str(args))
def __getattr__(*args):
raise Exception('called __getattr__ with %s' % str(args))

Z = Zmeta('Z', (), {'value': 42})
z = Z()

Exception: called __getattribute__ with (<class '__main__.Z'>, '__int__')

It appears (and is confirmed in: Metaclass Programming in Python Pt. 2
http://www-106.ibm.com/developerworks/library/l-pymeta2/?ca=dnt-434) that
metaclass attributes are available to instances (classes) but not instances
of instances.

Argh. Yes, now I think about the implementation, this isn't that
surprising. OTOH, one shouldn't have to know Objects/typeobject.c as
well as I do to avoid being surprised by Python...

I've added some more detailed comments to the bug report Michele
mentioned, if you're curious.

Cheers,
mwh

 

[Aahz]

You may also look at this bug report:

http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=789262

The special lookup of special attributes has bitten at least three or four
person on this mailing list in the last year or so: I maintain that
it is a documentation bug.

Just as a reminder, here's a nifty way of reporting SF URLs that makes
life easier:
http://www.python.org/sf/789262