Can a simple a==b 'hang' in and endless loop?

[Donn Cave]

In article <dqm366$qb9$1 at newsreader3.netcologne.de>,
 Claudio Grondi <claudio.grondi at freenet.de> wrote:
...
> It is probably true, that it doesn't much matter when writing Python 
> code when one do not understand how Python works internally. The rare 
> practical cases of getting into trouble because of lack of such 
> understanding can be easily overcome by performing some testing or 
> asking in the comp.lang.python .
> As I see, the question is here, if it is worth the effort to try to 
> change the way people speak about Python and understand what Python code 
> does in order to avoid this rare cases of getting into trouble?

Yes and no, mostly no.

The problem is that Python supports a lot of tricks and
gimmicks, and while each one of them was added with the
firmest conviction that it was a useful and important
feature, taken together they make what should be simple,
very complicated.

The ability to make __eq__ return a nonsensical value seems
to be the present example.  To be excruciatingly thorough,
an introduction to Python ought to account for this exception,
because in this case we can't predict in principle what "=="
means.  But this thorough introduction would not only be
confusing and unproductive, it would also inappropriately
confer some kind of legitimacy on absurd uses of __eq__.
It really is better to ignore this feature, except for the
occasional post on c.l.p. where we can use to shock and
horrify anyone who thought Python was really a simple language.

So this belongs in a different category from, say, lists and
dicts as default arguments.  That is a natural usage, where
__eq__ is sort of a perversion if you will, and a Python
programmer should know about it.

   Donn Cave, donn at u.washington.edu