[Python-porting] bugs in 2to3 tools when porting sympy

[Ondrej Certik]

On Sun, Jul 5, 2009 at 6:54 PM, Ondrej Certik<ondrej at certik.cz> wrote:
[...]
> I have a serious problem that the __hash__
> method is defined in the Basic() class, but in it's subclasses (Number
> and Symbol):
>
> Number.__hash__
>
> returns None, but
>
> Symbol.__hash__
>
> correctly points to the Basic.hash method. As a result, Number is not
> hashable and this breaks sympy. I already spent 2 hours debugging it,
> so far the only clue is that __slots__ influence it, but so far I
> wasn't able to isolate a simple failing testcase (if I create a simple
> class hierarchy, it works in python3.1), the problem is that it's not
> easy to delete just part of sympy -- it's either all or nothing, and
> thus it's very difficult to figure out why python3 behaves as it
> behaves.
>
> If anyone on this list has experience with debugging such kind of a
> problem in python 3, I would be interested in any input.

Here is how to reproduce it:

$ git clone git://github.com/certik/sympy.git
$ cd sympy
$ git checkout -b py3-hash-bug origin/py3-hash-bug
$ SYMPY_USE_CACHE=no python3.1 t.py
1
2
Atom: <function __hash__ at 0x1c0c270>
Number: None
Integer: None
Symbol: <function __hash__ at 0x1c0c270>

as you can see, the __hash__ method is defined in Basic and all Atom,
Number, Integer and Symbol are subclasses of Basic.

I must say I am totally puzzled as how this is possible.

Ondrej

P.S. The "SYMPY_USE_CACHE=no" is necessary, because otherwise sympy
will not import (due to this hash bug), as it can't cash things.