pre-PEP generic objects

[Tim Peters]

[Mel Wilson]

Seems to:


Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.... def __eq__(self, other):
... return True
...... def __eq__(self, other):
... print "(according to Neq)"
... return False
...(according to Neq)
False(according to Neq)
False

See the Python (language, not library) reference manual, section 3.3.8
("Coercion rules"), bullet point starting with:

Exception to the previous item: if the left operand is an
instance of a built-in type or a new-style class, and the right
operand is an instance of a proper subclass of that type or
class, ...

 

[Peter Otten]

See the Python (language, not library) reference manual, section 3.3.8
("Coercion rules"), bullet point starting with:

Exception to the previous item: if the left operand is an
instance of a built-in type or a new-style class, and the right
operand is an instance of a proper subclass of that type or
class, ...

So that is settled then. Not the most likely place to investigate when one
has just read that "Arguments to rich comparison methods are never coerced"
in 3.3.1 ("Basic customization"), though.

Peter

 

[Mel Wilson]

So that is settled then. Not the most likely place to investigate when one
has just read that "Arguments to rich comparison methods are never coerced"
in 3.3.1 ("Basic customization"), though.

At some point Python will cease to be a simple language.

Regards. Mel.

 

[Nick Coghlan]

Tim Peters wrote:




So that is settled then. Not the most likely place to investigate when one
has just read that "Arguments to rich comparison methods are never coerced"
in 3.3.1 ("Basic customization"), though.

<Heh - just reread this, and realised my reply below misses the point. You're
right that the subsection heading is a little misleading. . .>

Nothing is getting coerced. It's just that "A binop B" gets translated to a
method call differently depending on the types of A and B. The options being:

A.__binop__(B) # 1 - the usual case
B.__binop__(A) # 2.1 - commutative op, and B is a proper subclass of A
B.__rbinop__(A) # 2.2 - possibly non-commutative op, and B is a proper subclass of A

This is so that things like the following work:

..>>> class SillyAdd(long):
..... __add__ = long.__mul__
..... __radd__ = __add__
.....
..>>> a = SillyAdd(4)
..>>> a
..4L
..>>> a + 5
..20L
..>>> 5 + a
..20L

Cheers,
Nick.

 

[Ian Bicking]

Good point about being subclass friendly... I wonder if there's an easy
way of doing what update does though... Update (and therefore __init__)
allows you to pass in a Bunch, dict, (key, value) sequence or keyword
arguments by taking advantage of dict's update method. Is there a clean
way of supporting all these variants using setattr?

class bunch(object):
def __init__(self, __seq=None, **kw):
if __seq is not None:
if hasattr(__seq, 'keys'):
for key in __seq:
setattr(self, key, __seq[key])
else:
for name, value in __seq:
setattr(self, name, value)
for name, value in kw.items():
setattr(self, name, value)

That should match dict.update, at least from the 2.4 help(dict.update).
I'm not sure that will work for updating from a bunch object; also,
bunch objects could have a 'keys' attribute without being dictionaries.
Do you get attributes from non-iterables through their __dict__? I
don't care for that at all. Are bunch objects iterable?