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
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 ha
20 matches
Mail list logo
