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
[color=blue][color=green][color=darkred]
>>> y, z = Y(), Z()
>>> print int(y)[/color][/color][/color]
42[color=blue][color=green][color=darkred]
>>> print int(z)[/color][/color][/color]
TypeError: int() argument must be a string or a number

[Carmine Noviello]

Re: Type emulation issues with new style classes

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

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

--
Don't you know why your Python application has crashed?
Take a look to http://www.pycrash.org


--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

[Chris]

Re: Type emulation issues with new style classes

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.

"Carmine Noviello" wrote:[color=blue]
> class Z(object):
> value = 42
> def __hasattr__(sel f, name):
> if name == '__int__':
> return True
> def __int__(self):
> return self.value
>
>
> Umm, maybe I haven't understood what you need.[/color]

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]

Re: Type emulation issues with new style classes

In article <C0%%b.4538$qX5 .249@nwrdny03.g nilink.net>,
Chris <feb04.20.netma n@spamgourmet.c om> wrote:[color=blue]
>
>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[/color]

IIRC, __getattribute_ _ may do what you want, but I don't have time to
check.
--
Aahz (aahz@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

[Chris]

Re: Type emulation issues with new style classes

Tried it earlier, same result.

Chris

"Aahz" wrote:
[color=blue]
> IIRC, __getattribute_ _ may do what you want, but I don't have time to
> check.
> --
> Aahz (aahz@pythoncra ft.com) <*>[/color]
http://www.pythoncraft.com/[color=blue]
>
> "Do not taunt happy fun for loops. Do not change lists you are looping[/color]
over."[color=blue]
> --Remco Gerlich, comp.lang.pytho n[/color]

[Michael Hudson]

Re: Type emulation issues with new style classes

"Chris" <feb04.20.netma n@spamgourmet.c om> writes:
[color=blue]
> Is there any way to make the class Z behave the same way as class Y?[/color]

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

HTH.

Cheers,
mwh

--
Lisp does badly because we refuse to lie. When people ask us if
we can solve insoluble problems we say that we can't, and because
they expect us to lie to them, they find some other language
where the truth is less respected. -- Tim Bradshaw, comp.lang.lisp

[Chris]

Re: Type emulation issues with new style classes

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()
[color=blue][color=green][color=darkred]
>>> int(z)[/color][/color][/color]
TypeError: int() argument must be a string or a number[color=blue][color=green][color=darkred]
>>> z.__int__[/color][/color][/color]
AttributeError: 'Z' object has no attribute '__int__'[color=blue][color=green][color=darkred]
>>> Z.__int__[/color][/color][/color]
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.

Chris

"Michael Hudson" wrote:[color=blue]
>[color=green]
> > Is there any way to make the class Z behave the same way as class Y?[/color]
>
> You need a custom metaclass for Z, and implement __getattr__ there.
>
> HTH.
>
> Cheers,
> mwh
>
> --
> Lisp does badly because we refuse to lie. When people ask us if
> we can solve insoluble problems we say that we can't, and because
> they expect us to lie to them, they find some other language
> where the truth is less respected. -- Tim Bradshaw, comp.lang.lisp[/color]

[Rainer Deyke]

Re: Type emulation issues with new style classes

Chris wrote:[color=blue]
> 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[/color]
def __int__(self):
return self.__getattr_ _('__int__')()


--
Rainer Deyke - rainerd@eldwood .com - http://eldwood.com

[Greg Chapman]

Re: Type emulation issues with new style classes

On Sat, 28 Feb 2004 11:33:54 GMT, "Chris" <feb04.20.netma n@spamgourmet.c om>
wrote:
[color=blue]
>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[/color]

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

[Chris]

Re: Type emulation issues with new style classes

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__(sel f, name):
if name == '__coerce__':
raise AttributeError
if name == '__add__':
raise AttributeError
if name == '__radd__':
return lambda other: self.value + other.value
[color=blue][color=green][color=darkred]
>>> y1, y2 = Y(), Y()
>>> print int(y1) #This works[/color][/color][/color]
42[color=blue][color=green][color=darkred]
>>> print y1 + y2 #This works too[/color][/color][/color]
84

class Z(object):
value = 42
def __getattr__(sel f, 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__')()

[color=blue][color=green][color=darkred]
>>> z1, z2 = Z(), Z()
>>> # This following will work now, after explicitly
>>> # adding __int__ to the namespace of Z, which I'm
>>> # trying to avoid.
>>> print int(z1)[/color][/color][/color]
42[color=blue][color=green][color=darkred]
>>> print y1 + y2 # This bombs[/color][/color][/color]
TypeError: 'NoneType' object is not callable

"Rainer Deyke" wrote:[color=blue]
> Chris wrote:[color=green]
> > 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[/color]
> def __int__(self):
> return self.__getattr_ _('__int__')()
>
>
> --
> Rainer Deyke - rainerd@eldwood .com - http://eldwood.com
>
>[/color]

[Chris]

Re: Type emulation issues with new style classes

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
[color=blue][color=green][color=darkred]
>>> y1, y2 = Y(), Y()
>>> print int(y1)[/color][/color][/color]
42[color=blue][color=green][color=darkred]
>>> print y1 + y2[/color][/color][/color]
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__")
[color=blue][color=green][color=darkred]
>>> z1, z2 = Z(), Z()
>>> print int(z1)[/color][/color][/color]
42[color=blue][color=green][color=darkred]
>>> print z1 + z2[/color][/color][/color]
AttributeError: __add__


"Greg Chapman" wrote:[color=blue]
> On Sat, 28 Feb 2004 11:33:54 GMT, "Chris"[/color]
<feb04.20.netma n@spamgourmet.c om>[color=blue]
> wrote:
>[color=green]
> >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[/color]
>
> The following allows your test case to work, but it may have various[/color]
subtle[color=blue]
> problems. AddDynOper emulates __getattr__ semantics: the descriptor is[/color]
not[color=blue]
> 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
>[/color]

[Rainer Deyke]

Re: Type emulation issues with new style classes

Chris wrote:[color=blue]
> 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).[/color]

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):
...
[color=blue]
> 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__.[/color]

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


--
Rainer Deyke - rainerd@eldwood .com - http://eldwood.com

[Michele Simionato]

Re: Type emulation issues with new style classes

"Chris" <feb04.20.netma n@spamgourmet.c om> wrote in message news:<Fz30c.722 0$TF2.5832@nwrd ny02.gnilink.ne t>...[color=blue]
> 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[/color]

You may want to look at this thread:

http://groups.google.it/groups?hl=it&lr=&ie=UTF-8&threadm=2259b0e2.0311240603.549943b3%40posting.google.com&rnum=1&prev=/groups%3Fhl%3Dit%26lr%3D%26ie%3DISO-8859-1%26q%3Dinnermethods%26meta%3Dgroup%253Dcomp.lang.python.*

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

Michele Simionato

[Michele Simionato]

Re: Type emulation issues with new style classes

"Chris" <feb04.20.netma n@spamgourmet.c om> wrote in message news:<6O40c.596 9$qX5.1972@nwrd ny03.gnilink.ne t>...[color=blue]
> 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.[/color]

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]

Re: Type emulation issues with new style classes

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:[color=blue]
> "Chris" <feb04.20.netma n@spamgourmet.c om> wrote in message[/color]
news:<6O40c.596 9$qX5.1972@nwrd ny03.gnilink.ne t>...[color=blue][color=green]
> > 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[/color][/color]
a[color=blue][color=green]
> > class derived from that metaclass.[/color]
>
> You may also look at this bug report:
>
>[/color]
http://sourceforge.net/tracker/?grou...ail&aid=789262[color=blue]
>
> 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[/color]