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__(sel f, name):
if name == '__int__':
return True
def __getattr__(sel f, name):
if name == '__int__':
return lambda: self.value

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

y, z = Y(), Z()
print int(y) 42 print int(z)

TypeError: int() argument must be a string or a number

[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__(sel f, 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

y1, y2 = Y(), Y()
print int(y1) 42 print y1 + y2 84
### With new style classes, __radd__ is never called ###
class DynOperDescr(ob ject):
def __init__(self, name):
self.name = name
def __get__(self, instance, typ):
if instance is None:
return self
return instance.__geta ttr__(self.name )

def AddDynOper(decl cls, name):
if not hasattr(declcls , name):
setattr(declcls , name, DynOperDescr(na me))

class Z(object):
value = 42
def __getattr__(sel f, 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__")
z1, z2 = Z(), Z()
print int(z1) 42 print z1 + z2

AttributeError: __add__
"Greg Chapman" wrote: On Sat, 28 Feb 2004 11:33:54 GMT, "Chris" <fe************ *@spamgourmet.c om> wrote:

class Z(object):
value = 42
def __hasattr__(sel f, name):
if name == '__int__':
return True
def __getattr__(sel f, 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(ob ject):
def __init__(self, name):
self.name = name
def __get__(self, instance, typ):
if instance is None:
return self
return instance.__geta ttr__(self.name )

def AddDynOper(decl cls, name):
if not hasattr(declcls , name):
setattr(declcls , name, DynOperDescr(na me))

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

---
Greg Chapman

[Rainer Deyke]

Chris wrote:

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 IndirectionMixi ns(object):
pass

def add_indirection _method(name):
def f(self, *args, **kwargs):
return self.__getattr_ _(name)(*args, **kwargs)
setattr(Indirec tionMixins, name, f)

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

class Y(IndirectionMi xins):
...
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.
--
Rainer Deyke - ra*****@eldwood .com - http://eldwood.com

[Michele Simionato]

"Chris" <fe************ *@spamgourmet.c om> wrote in message news:<Fz******* **********@nwrd ny02.gnilink.ne t>...

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=it....lang.python.*

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

Michele Simionato

[Michele Simionato]

"Chris" <fe************ *@spamgourmet.c om> wrote in message news:<6O******* **********@nwrd ny03.gnilink.ne t>...

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/?grou...ail&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

"Michele Simionato" wrote:

"Chris" <fe************ *@spamgourmet.c om> wrote in message news:<6O******* **********@nwrd ny03.gnilink.ne t>...

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/?grou...ail&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

[Michael Hudson]

"Chris" <fe************ *@spamgourmet.c om> writes:

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('call ed __getattribute_ _ with %s' % str(args))
def __getattr__(*ar gs):
raise Exception('call ed __getattr__ with %s' % str(args))

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

int(z) TypeError: int() argument must be a string or a number z.__int__ AttributeError: 'Z' object has no attribute '__int__' Z.__int__

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/developerwork...a2/?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

--
SCSI is not magic. There are fundamental technical reasons why it
is necessary to sacrifice a young goat to your SCSI chain now and
then. -- John Woods

[Aahz]

In article <95************ **************@ posting.google. com>,
Michele Simionato <mi************ ***@poste.it> wrote:

You may also look at this bug report:

http://sourceforge.net/tracker/?grou...ail&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
--
Aahz (aa**@pythoncra ft.com) <*> http://www.pythoncraft.com/

"Do not taunt happy fun for loops. Do not change lists you are looping over."
--Remco Gerlich, comp.lang.pytho n