In article <[EMAIL PROTECTED]>, Claudio Grondi <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
