New style classes and rich comparison

  • Thread starter Stian =?iso-8859-1?Q?S=F8iland?=
  • Start date
S

Stian =?iso-8859-1?Q?S=F8iland?=

Could anyone explain to me why this does not work as intended?
.... pass
....True

Nice and fine.

False

Doesn't work!


It seems that __eq__ is fetched directly from newbie's class, not from
newbie.
True

Adding a method __getattribute__ that prints the key and then calls
object.__getattribute__ proves this - nothing is printed for comparison.

This goes even for hash():
15



Why is this? Where is this documented?



Here's my real goal, to create a Dummy class that supports anything:

from dummy.py:

class Dummy(object):
"""An object that can do anything in the world"""
def __call__(self, *args, **kwargs):
"""Can be called with any kind of parameters, returns
a new Dummy."""
return Dummy()
def __getattribute__(self, key):
"""Any attribute created and stored on demand. All
attributes are new Dummys."""
try:
value = object.__getattribute__(self, key)
except AttributeError:
value = self()
# remember it to next time! =)
setattr(self, key, value)
return value

This dummy can be used for many things:
<dummy.Dummy object at 0x81f3764>


Now the trouble is that __operator__ is not resolved as I would expect.
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: unsupported operand types for +: 'Dummy' and 'Dummy'


Why are operators looked up in the class instead of the object? How
can I modify my Dummy class to return 'anything' even directly in the
class?

Ie. what I probably want is something like this (simulated):
<dummy.Dummy object at 0x81ad4dc>

That way Dummy.__add__ would return a new Dummy instance, and
Dummy() + Dummy() would work as expected.

My first attempt was to manually define different __operator__-methods
in the dummy, but this got rather boring. Can I use __metaclass__ or
something?
 
S

Stian =?iso-8859-1?Q?S=F8iland?=

* Rainer Deyke spake thusly:
Consider:

class A(object):
def __hash__(self): return 5
print hash(A) # Which function should this call?

The hash method of A's class, ie. A.__class__.__hash__, usually
type.__hash__.

Hmmm. I think I get your point. hash and cmp and so on should call
A.__class__.hash(A) to be generic enough.

It's still confusing.. =) And how should I resolve this issue with my
Dummy class? (it's ok for the Dummy class itself to be a Dummy, but it
didn't work well to make Dummy = Dummy())
 
M

Michael Hudson

Could anyone explain to me why this does not work as intended?
[snippo]

It seems that __eq__ is fetched directly from newbie's class, not from
newbie.

Yup! One of the differences between new-style and old-style classes.

To see why something has to be a bit like this, consider the
difference between a unbound method for the instance and a bound
method for the *type* of the instance...

[biggo snippo]
Can I use __metaclass__ or something?

I think that's what you want, yes.

Cheers,
mwh
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,995
Messages
2,570,228
Members
46,817
Latest member
AdalbertoT

Latest Threads

Top