Question about isinstance()

[bruno at modulix]

Re: Question about isinstance()

bruno at modulix wrote:[color=blue]
> Dave Benjamin wrote:
> (snip)
>
>[color=green]
>>You *could* have "b.__eq__" just call "a.__eq__",[/color]
>
>
> Which could lead to strange results (well, actually a good ole infinite
> recursion) if b.__eq__ happens to call b.__eq__ too !-)[/color]

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 'onurb@xiludom. gro'.split('@')])"

[Magnus Lycka]

Re: Question about isinstance()

Mr.Rech wrote:[color=blue]
> 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.[/color]
[snip][color=blue]
> Any better way to write this method? Any suggestion?[/color]

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]

Re: Question about isinstance()

Magnus Lycka:[color=blue]
>isinstance() wouldn't be in Python if you weren't supposed to use it,[/color]

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

--
René Pijlman

[Marc 'BlackJack' Rintsch]

Re: Question about isinstance()

In <c2rjt15o8bsg7h 6114jf45tf6r680 058om@4ax.com>, Rene Pijlman wrote:
[color=blue]
> Steven D'Aprano:[color=green]
>>Rene Pijlman:[color=darkred]
>>> Mr.Rech:
>>>> def __eq__(self, other):
>>>> try:
>>>> return self.an_attribu te == other.an_attrib ute
>>>> 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'.[/color]
>>
>>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.[/color]
>
> 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.[/color]

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]

Re: Question about isinstance()

Marc 'BlackJack' Rintsch:[color=blue]
>Rene Pijlman:[color=green]
>> 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.[/color]
>
>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`.[/color]

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

--
René Pijlman