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
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 result
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
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 fro
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
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 comple
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 wort
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.
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(
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 compare
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 m
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:
>>
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
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
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. Th
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_at
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 h
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
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 compar
19 matches
Mail list logo
