Error with the latest scipy

[jtsuru]

numba raised an exception with the latest version of scipy and numpy when numba-scipy is installed.
I installed all the packages from pypi, and ran the following script on Windows 10 x64 with Python 3.7.5.

Test code:

import numba as nb
import numpy
import numba_scipy
import scipy

@nb.jit
def testfunc():
    return 1.0

print("numpy: ", numpy.__version__)
print("scipy: ", scipy.__version__)
print("numba_scipy: ", numba_scipy.__version__)
print(testfunc())

With old numpy and scipy:

numpy:  1.17.4
scipy:  1.3.3
numba_scipy:  0.2.0
1.0

With the latest numpy and scipy:

numpy:  1.18.1
scipy:  1.4.1
numba_scipy:  0.2.0
Traceback (most recent call last):
  File "numbatest.py", line 13, in <module>
    print(testfunc())
  File "C:\Python37\lib\site-packages\numba\dispatcher.py", line 420, in _compile_for_args
    raise e
  File "C:\Python37\lib\site-packages\numba\dispatcher.py", line 353, in _compile_for_args
    return self.compile(tuple(argtypes))
  File "C:\Python37\lib\site-packages\numba\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "C:\Python37\lib\site-packages\numba\dispatcher.py", line 768, in compile
    cres = self._compiler.compile(args, return_type)
  File "C:\Python37\lib\site-packages\numba\dispatcher.py", line 77, in compile
    status, retval = self._compile_cached(args, return_type)
  File "C:\Python37\lib\site-packages\numba\dispatcher.py", line 91, in _compile_cached
    retval = self._compile_core(args, return_type)
  File "C:\Python37\lib\site-packages\numba\dispatcher.py", line 109, in _compile_core
    pipeline_class=self.pipeline_class)
  File "C:\Python37\lib\site-packages\numba\compiler.py", line 550, in compile_extra
    args, return_type, flags, locals)
  File "C:\Python37\lib\site-packages\numba\compiler.py", line 281, in __init__
    targetctx.refresh()
  File "C:\Python37\lib\site-packages\numba\targets\base.py", line 281, in refresh
    self.load_additional_registries()
  File "C:\Python37\lib\site-packages\numba\targets\cpu.py", line 80, in load_additional_registries
    numba.entrypoints.init_all()
  File "C:\Python37\lib\site-packages\numba\entrypoints.py", line 24, in init_all
    func()
  File "C:\Python37\lib\site-packages\numba_scipy\__init__.py", line 12, in _init_extension
    from . import special
  File "C:\Python37\lib\site-packages\numba_scipy\special\__init__.py", line 1, in <module>
    from . import overloads as _overloads
  File "C:\Python37\lib\site-packages\numba_scipy\special\overloads.py", line 4, in <module>
    from . import signatures
  File "C:\Python37\lib\site-packages\numba_scipy\special\signatures.py", line 376, in <module>
    ('pdtr', numba.types.float64, numba.types.float64): ctypes.CFUNCTYPE(ctypes.c_double, ctypes.c_double, ctypes.c_double)(get_cython_function_address('scipy.special.cython_special', '__pyx_fuse_0pdtr')),
  File "C:\Python37\lib\site-packages\numba\extending.py", line 405, in get_cython_function_address
    return _import_cython_function(module_name, function_name)
ValueError: No function '__pyx_fuse_0pdtr' found in __pyx_capi__ of 'scipy.special.cython_special'

[person142]

Ooh that one is my fault. I removed that signature from pdtr in SciPy 1.4, which happened to be back compatible on the special side but not on the cython_special side.

[stuartarchibald]

@jtsuru thanks for the report.

@person142 any idea what are the options here? Does the binding need to become SciPy version specific perhaps? Thanks.

[person142]

Does the binding need to become SciPy version specific perhaps?

Yeah I think you could either pin releases to a corresponding SciPy release or have an internal blacklist that gives invalid ranges of SciPy versions for functions. In this case I shouldn’t have broke back-compat and might need to fix that on the SciPy side, but from the same release there’s also the new function voigt_profile which will have the same problems, so the issue is here to stay.

[jvines]

It seems it works with scipy 1.2.1

[esc]

SciPy 1.3.1 also. I think this is the last working SciPy for this project in it's current state.

[esc]

Now that #54 has been merged I do believe the above reported issue should be resolved on mainline (master). I will close this issue now as a consequence but do feel free to re-open (or open a new issue) in case that issues do unexpectedly persist.