Re: Question about isinstance()
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
In <[EMAIL PROTECTED]>, 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
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__. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
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 '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
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 '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
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 '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
All in all it seems that the implementation that uses isinstance() is better in this case... Thanks for your comments, Andrea. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
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__". -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about isinstance()
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 -- http://mail.python.org/mailman/listinfo/python-list
