Question about isinstance()

[Mr.Rech]

Hi all,
I've read some thread about isinstance(), why it is considered harmful
and how you can achieve the same results using a coding style that
doesn't break polymorphism etc... Since I'm trying to improve my Python
knowledge, and I'm going to design a class hierarchy from scratch, I'd
like to have some feedback about this from those of you much more
experienced than me in OOP.

Suppose I'm writing a base class with an __eq__ special methods, using
isinstance() I would have wrote:

class foo(object):
...
def __eq__(self, other):
return isinstance(other, type(self)) and self.an_attribute ==
other.an__attribute

Now, avoiding isinstace() I've written the following code:

class foo(object):
...
def __eq__(self, other):
try:
return self.an_attribute == other.an_attribute
except AttributeError:
return False

Any better way to write this method? Any suggestion?

[Rene Pijlman]

Mr.Rech:

Now, avoiding isinstace() I've written the following code:

class foo(object):
...
def __eq__(self, other):
try:
return self.an_attribute == other.an_attribute
except AttributeError:
return False

This may give unexpected results when you compare a foo with an instance
of a completely different type that happens to have an attribute called
'an_attribute'.

--
René Pijlman

Wat wil jij worden? http://www.carrieretijger.nl

[Mr.Rech]

Mmm... I've not considered such an event... Would you say it is one of
those rare case in which isinstance() "can be used"? Any other
suggestion?

Thanks,
Andrea

[Dave Benjamin]

On Thu, 26 Jan 2006, Mr.Rech wrote:

I've read some thread about isinstance(), why it is considered harmful
and how you can achieve the same results using a coding style that
doesn't break polymorphism etc... Since I'm trying to improve my Python
knowledge, and I'm going to design a class hierarchy from scratch, I'd
like to have some feedback about this from those of you much more
experienced than me in OOP.
When trying to write OO code, you should of course always be suspicious of
any use of "isinstance". However, it is not always "considered harmful",
and this is one case where it is perfectly reasonable.
Now, avoiding isinstace() I've written the following code:

class foo(object):
...
def __eq__(self, other):
try:
return self.an_attribute == other.an_attribute
except AttributeError:
return False

You were better off with what you had before. Equality in this case is
left completely open-ended, and as a result, there is no way that you can
guarantee that "a == b" is the same as "b == a" if "a" is a "foo" and "b"
is of unknown type. This can lead to bizarre and unpredictable behavior.

--
.:[ dave benjamin -( ramen/sp00 )- http://spoomusic.com/ ]:.

"To attain knowledge, add things every day.
To attain wisdom, remove things every day." - Lao Tzu

[Rocco Moretti]

Dave Benjamin wrote:

On Thu, 26 Jan 2006, Mr.Rech wrote:

Suppose I'm writing a base class with an __eq__ special methods, using
isinstance() I would have wrote:

class foo(object):
...
def __eq__(self, other):
return isinstance(other, type(self)) and self.an_attribute ==
other.an__attribute Now, avoiding isinstace() I've written the following code:

class foo(object):
...
def __eq__(self, other):
try:
return self.an_attribute == other.an_attribute
except AttributeError:
return False

You were better off with what you had before. Equality in this case is
left completely open-ended, and as a result, there is no way that you
can guarantee that "a == b" is the same as "b == a" if "a" is a "foo"
and "b" is of unknown type. This can lead to bizarre and unpredictable
behavior.

Mind explaining that better? b == a *always* calls b.__eq__(a), if it
exists. What a.__eq__(b) is doesn't matter at that point. So you have
the same problems either way.

The only difference between the two is in the case where b is of an
unrelated class and b.an_attribute exists (1). In this case, the first
always returns False, and the second returns (a.an_attribute ==
b.an_attribute). Which you prefer depends on how strictly you adhere to
duck typing.

(1) To be honest, they also vary when a.an_attribute is undefined. The
second always returns False, and the first raises an AttributeError.

[Dave Benjamin]

On Thu, 26 Jan 2006, Rocco Moretti wrote:

You were better off with what you had before. Equality in this case is left
completely open-ended, and as a result, there is no way that you can
guarantee that "a == b" is the same as "b == a" if "a" is a "foo" and "b"
is of unknown type. This can lead to bizarre and unpredictable behavior.
Mind explaining that better? b == a *always* calls b.__eq__(a), if it exists.
What a.__eq__(b) is doesn't matter at that point. So you have the same
problems either way.

Right, but we don't know what "b.__eq__" does, since "b" could be
anything, if it exists at all. So, it's quite possible that "a == b",
since "a.__eq__" is defined and only depends on "b" having an
attribute named "an_attribute", but "b == a" is:

a) an error
b) false, even though "a == b" is true

If we control the class of "a" and the class of "b", we can ensure that
the two "__eq__" methods behave identically. The problem is that, in the
supposed interest of "polymorphism" we are relaxing the dependency on
"a.__eq__"'s parameter so that it can be any class with "an_attribute".
This implies that we would like other classes besides those we control to
be able to participate in equality tests with the class of "a". However,
to do this properly, we need to be able to modify *both classes*, or we
will have inconsistent results depending on whether we say "a == b" or
"b == a". It is reasonable to expect that these two expressions produce
the same result, isn't it?
The only difference between the two is in the case where b is of an unrelated
class and b.an_attribute exists (1). In this case, the first always returns
False, and the second returns (a.an_attribute == b.an_attribute). Which you
prefer depends on how strictly you adhere to duck typing.

I don't think duck typing buys you anything valuable here. The usual
flexibility of duck typing is lost because of the symmetric nature of
equality; all participating classes need to be involved to guarantee
correctness. You *could* have "b.__eq__" just call "a.__eq__", but once
again this assumes we have control over the implementation of "b".

--
.:[ dave benjamin -( ramen/sp00 )- http://spoomusic.com/ ]:.

"To attain knowledge, add things every day.
To attain wisdom, remove things every day." - Lao Tzu

[Dave Benjamin]

On Thu, 26 Jan 2006, Dave Benjamin wrote:

On Thu, 26 Jan 2006, Rocco Moretti wrote:

You were better off with what you had before. Equality in this case is
left completely open-ended, and as a result, there is no way that you can
guarantee that "a == b" is the same as "b == a" if "a" is a "foo" and "b"
is of unknown type. This can lead to bizarre and unpredictable behavior.

Mind explaining that better? b == a *always* calls b.__eq__(a), if it
exists. What a.__eq__(b) is doesn't matter at that point. So you have the
same problems either way.

Right, but we don't know what "b.__eq__" does, since "b" could be anything,
if it exists at all. So, it's quite possible that "a == b", since "a.__eq__"

^^^^^^^^^^^^^^^^^^^

By "it" here, I mean "b.__eq__".

[Mr.Rech]

All in all it seems that the implementation that uses isinstance() is
better in this case...

Thanks for your comments,
Andrea.

[Steven D'Aprano]

On Thu, 26 Jan 2006 19:04:13 +0100, Rene Pijlman wrote:

Mr.Rech:

Now, avoiding isinstace() I've written the following code:

class foo(object):
...
def __eq__(self, other):
try:
return self.an_attribute == other.an_attribute
except AttributeError:
return False

This may give unexpected results when you compare a foo with an instance
of a completely different type that happens to have an attribute called
'an_attribute'.

That's a trade-off, isn't it?
On the one hand, you risk false negatives, by refusing to compare against
things you didn't think of. On the other hand, you risk false positives,
by comparing against more generic objects.

I guess that trade-off is one each programmer must decide for herself, in
full understanding of the pros and cons of each method.
--
Steven.

[Rocco Moretti]

Mr.Rech wrote:

All in all it seems that the implementation that uses isinstance() is
better in this case...

Well what's "better" depends on what you want to happen when you compare
an unrelated class that also defines 'an_attribute'. Unlike in
statically typed languages, certain things are made easier when you
don't check for strict inheritance (like mock and proxy objects). Google
"Duck Typing" for more info.

[Mr.Rech]

After reading all your comments and thinking a little to my specific
case, I think it is definetively better to go with the "isinstance()"
implementation. My objects represent mathematical function defined over
a numerical grid, and I hardly think of an unrelated class objects that
could be compared with them in a meaningfull way.

Thanks again to all of you for helping me to better understand another
piece of the Python's world. ;-)

Andrea

[bruno at modulix]

Dave Benjamin wrote:
(snip)

You *could* have "b.__eq__" just call "a.__eq__",

Which could lead to strange results (well, actually a good ole infinite
recursion) if b.__eq__ happens to call b.__eq__ too !-)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[bruno at modulix]

Mr.Rech wrote:

All in all it seems that the implementation that uses isinstance() is
better in this case...

You could also use something like Zope's Interfaces... But I'm not sure
it's worth the extra complexity.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Mr.Rech]

bruno at modulix wrote:

Mr.Rech wrote:

All in all it seems that the implementation that uses isinstance() is
better in this case...

You could also use something like Zope's Interfaces... But I'm not sure
it's worth the extra complexity.

Thanks for your suggestion, but it's not worth the extra complexity at
all.

I've read something about interfaces, but my project will be a
small/middle sized one, and using such a sophisticated tool it would be
like using a cannon to shoot a sparrow (as we are used to say here in
Italy).

Anyway thanks again for your comments.

Andrea

[Rene Pijlman]

Steven D'Aprano:

Rene Pijlman:

Mr.Rech:

def __eq__(self, other):
try:
return self.an_attribute == other.an_attribute
except AttributeError:
return False

This may give unexpected results when you compare a foo with an instance
of a completely different type that happens to have an attribute called
'an_attribute'.

That's a trade-off, isn't it?

On the one hand, you risk false negatives, by refusing to compare against
things you didn't think of.

Well no, when comparing against things you didn't think of the __eq__
shouldn't return a false False, it should return NotImplemented. After
all, the things you didn't think of are not (yet) implemented.

"A rich comparison method may return NotImplemented if it does not
implement the operation for a given pair of arguments."
http://www.python.org/doc/ref/customization.html

--
René Pijlman

Wat wil jij worden? http://www.carrieretijger.nl

[bruno at modulix]

bruno at modulix wrote:

Dave Benjamin wrote:
(snip)

You *could* have "b.__eq__" just call "a.__eq__",

Which could lead to strange results (well, actually a good ole infinite
recursion) if b.__eq__ happens to call b.__eq__ too !-)

I meant:

'if a.__eq__ happens to call b.__eq__ too'

of course...

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Magnus Lycka]

Mr.Rech wrote:

Hi all,
I've read some thread about isinstance(), why it is considered harmful
and how you can achieve the same results using a coding style that
doesn't break polymorphism etc... Since I'm trying to improve my Python
knowledge, and I'm going to design a class hierarchy from scratch, I'd
like to have some feedback about this from those of you much more
experienced than me in OOP. [snip] Any better way to write this method? Any suggestion?

It's really impossible to tell what's good Python code
based on details like this. isinstance() wouldn't be in
Python if you weren't supposed to use it, but you need to
understand when you should limit your functions to work
with a specific kind of data, and when you should try to
be broader. This is a design decision that will influence
the usability and maintainability of your code. We can't
help you figure out how to make such trade-offs based on
your implementation of __eq__.

[Rene Pijlman]

Magnus Lycka:

isinstance() wouldn't be in Python if you weren't supposed to use it,

If this argument was correct, 'goto' wouldn't be in Pascal :-)

--
René Pijlman

[Marc 'BlackJack' Rintsch]

In <c2********************************@4ax.com>, Rene Pijlman wrote:

Steven D'Aprano:

Rene Pijlman:

Mr.Rech:
def __eq__(self, other):
try:
return self.an_attribute == other.an_attribute
except AttributeError:
return False

This may give unexpected results when you compare a foo with an instance
of a completely different type that happens to have an attribute called
'an_attribute'.

That's a trade-off, isn't it?

On the one hand, you risk false negatives, by refusing to compare against
things you didn't think of.

Well no, when comparing against things you didn't think of the __eq__
shouldn't return a false False, it should return NotImplemented. After
all, the things you didn't think of are not (yet) implemented.

I think Steven thinks that it is possible that you compare to an object of
a different type which has the same attributes as expected by the
`__eq__()` method. If the first test is `isinstance()` for the "correct"
type you rule out those cases and give a false `False`.

Ciao,
Marc 'BlackJack' Rintsch

[Rene Pijlman]

Marc 'BlackJack' Rintsch:

Rene Pijlman:

Well no, when comparing against things you didn't think of the __eq__
shouldn't return a false False, it should return NotImplemented. After
all, the things you didn't think of are not (yet) implemented.

I think Steven thinks that it is possible that you compare to an object of
a different type which has the same attributes as expected by the
`__eq__()` method. If the first test is `isinstance()` for the "correct"
type you rule out those cases and give a false `False`.

Like I said, it wouldn't return False, it would return NotImplemented.

--
René Pijlman