You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We found that our regular Python code compiled with Cython behaves differently from the original. The issue appears to be with boolean constants being treated as if they were integers 0/1 (or the other way around). The following MRE reproduces the problem:
dt.pyx
# cython: language_level=3
def test():
j = (False, False)
k = (0, 0)
if k[0] is False or k[1] is False:
raise AssertionError("Oh noes! k = %r" % (k,))
print("ok")
setup.py
from distutils.core import setup
from Cython.Build import cythonize
setup(ext_modules = cythonize('dt.pyx'))
$ python
Python 3.6.6 (v3.6.6:4cf1f54eb7, Jun 26 2018, 19:50:54)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from dt import test
>>> test()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "dt.pyx", line 7, in dt.test
raise AssertionError("Oh noes! k = %r" % (k,))
AssertionError: Oh noes! k = (False, False)
>>>
>>> def test():
... j = (False, False)
... k = (0, 0)
... if k[0] is False or k[1] is False:
... raise AssertionError("Oh noes! k = %r" % (k,))
... print("ok")
...
>>> test()
ok
>>>
Thanks for the report. My guess is that both tuples are treated as typed ctuples, but that the type deduplication for them does not distinguish the int and bint types and joins both together into (bint, bint). It probably also depends on the order in which you define the tuples.
The deduplication happens in declare_tuple_type() in Symtab.py. It's worth investigating how the hashing and comparison works for the types at hand, to see what can be improved there.
Wasn't the ctuples after all. What happened, instead, was that the deduplication of Python tuple constants, while taking the type into account, didn't know the concrete Python object type in this case, considering it "some Python object", and thus throwing the two tuple constants together. I pushed a fix that also considers the Python type of the known constant value, so that False, 0 and 0.0 are assigned different deduplication keys.
We found that our regular Python code compiled with Cython behaves differently from the original. The issue appears to be with boolean constants being treated as if they were integers 0/1 (or the other way around). The following MRE reproduces the problem:
dt.pyx
setup.py
Buillding
Running
Using Cython version 0.29.6 (https://files.pythonhosted.org/packages/d0/27/d7e796420dd1c69135ccf1362cd8ecf61a09db990a8335d65cd715b275b6/Cython-0.29.6-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl)
The text was updated successfully, but these errors were encountered: