search

libdynd / dynd-python

Python exposure of dynd
http://libdynd.org
Other
119 stars 23 forks source link

ndt depends on nd.registry #743

Open skrah opened 7 years ago

skrah commented 7 years ago

After the registry changes the ndt module depends on nd again:

$ /home/stefan/gcc/bin/python3 setup.py --target=ndt install
...

$ /home/stefan/gcc/bin/python3 -m dynd.ndt.test             
Traceback (most recent call last):
  File "/home/stefan/gcc/lib/python3.6/runpy.py", line 174, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/home/stefan/gcc/lib/python3.6/runpy.py", line 109, in _get_module_details
    __import__(pkg_name)
  File "/home/stefan/dynd-python/dynd/__init__.py", line 23, in <module>
    from .nd.registry import propagate_all
  File "/home/stefan/dynd-python/dynd/nd/__init__.py", line 10, in <module>
    from .array import array, asarray, type_of, dshape_of, as_py, view, \
ImportError: No module named 'dynd.nd.array'
insertinterestingnamehere commented 7 years ago

Right. The registry needs to be moved to be a part of the type module. The whole point of a dynamic registry is to have dynamic registration of both types and callables. It doesn't make sense to limit that to the callable library. The CI tests have been broken for a little while because of that, but I'm working on fixing it.

mwiebe commented 7 years ago

That's the callable registry, though, I don't think the type registry is exposed in the Python bindings right now.

insertinterestingnamehere commented 7 years ago

Ah. My mistake. That means that the fixes in https://github.com/libdynd/dynd-python/pull/742 should be enough to fix this, but that also means that we don't need to move the registry file like I suggested in the description.