Move Array creation to its own module and out of Context#252
Conversation
|
It looks like both Py2 and Py3 hang on |
cowlicks
changed the title
ContextContext
|
This is pretty weird. I think it might be an issue with multiple |
|
@cowlicks please look into the Travis failures. |
|
I've seen errors like this before -- will take a look once I have some bandwidth... |
|
I've tracked down this bug -- it's the same Will put it in a separate issue. |
|
@kwmsmith done |
|
It's kind of weird to have Also, should we put |
|
I like the idea of naming consistency. These would do the same thing as class methods except it would be awkward to write |
|
We could have a fully consistent core with That would provide an easier path for people to get things working with existing NumPy code, and then gradually shift over to the core API when they want to use |
|
The test suite seems to be hanging on my local machine. With Python3, it hangs right after
With Python2, it hangs after a umath test... details forthcoming. I restarted the tests on Travis just to see if they pass again. |
|
Now Python2 is hanging while running and HDF5 test... |
|
Travis seems to be passing. Anyone else seeing hangs locally on OS X? I'm having trouble reproducing it now. |
|
No hangs for me. |
|
Closes #192 |
There was a problem hiding this comment.
Can you go into detail why it leads to a circular import? What are the circular dependencies? I'd like to see if we can resolve the circular dependency rather than using a decorator.
While this decorator solves the problem, it does it in a way that strikes me as too implicit. I think something like this would be more explicit; am curious what your thoughts are:
def zeros(..., context=None, ...):
context = context or WORLD
...It's one extra line per function, but it's fairly trivial, as long as we can resolve the circular dependency issue. And if we can't, then it's just two lines -- one for the import, and one for the assignment.
There was a problem hiding this comment.
I think the steps are:
import distarray- in
__init__.pywe dofrom distarray.creation import * - in there we do
from distarray.world import WORLD. - which does
from distarray.context import Context - which does
import distarray(goto 1.)
But I don't think client.py needs to do import distarray it could probably do import distarray.functions as ... instead. I'll try it out.
There was a problem hiding this comment.
This python -vv output is a little more helpful:
import distarray # directory distarray
# distarray/__init__.pyc matches distarray/__init__.py
import distarray # precompiled from distarray/__init__.pyc
# distarray/creation.pyc matches distarray/creation.py
import distarray.creation # precompiled from distarray/creation.pyc
# distarray/world.pyc matches distarray/world.py
import distarray.world # precompiled from distarray/world.pyc
Exception AttributeError: "'Context' object has no attribute 'key_context'" in <bound method Context.__del__ of <distarray.context.Context object at 0x109ae9f90>> ignored
import distarray # directory distarray
# distarray/__init__.pyc matches distarray/__init__.py
import distarray # precompiled from distarray/__init__.pyc
# distarray/creation.pyc matches distarray/creation.py
import distarray.creation # precompiled from distarray/creation.pyc
# distarray/world.pyc matches distarray/world.py
import distarray.world # precompiled from distarray/world.pyc
Exception AttributeError: "'Context' object has no attribute 'key_context'" in <bound method Context.__del__ of <distarray.context.Context object at 0x10afd9890>> ignored
import distarray # directory distarray
# distarray/__init__.pyc matches distarray/__init__.py
import distarray # precompiled from distarray/__init__.pyc
# distarray/creation.pyc matches distarray/creation.py
import distarray.creation # precompiled from distarray/creation.pyc
# distarray/world.pyc matches distarray/world.py
import distarray.world # precompiled from distarray/world.pyc
Exception AttributeError: "'Context' object has no attribute 'key_context'" in <bound method Context.__del__ of <distarray.context.Context object at 0x10afd9890>> ignored
|
Hangs on OSX seem to be fixed by upgrading to the pyzmq which is available on pypi (14.1.1). It is unclear what version of pyzmq is required but hangs were seen with v13.1.0 |
|
rebased |
|
@cowlicks as I think about this PR, I'm concerned about the required upgrade to a newer version of zeromq / pyzmq. IPython is used widely, and I'd like to be able to sit on top of existing IPython installations that aren't the latest -- if we tell people that they have to upgrade their IPython (or underlying components of IPython), then that may drive many away. At the very least, I'd like to better understand what is causing the issue here, and what changed in recent versions of zmq / pyzmq to fix the issue. That could take a while. To help resolve this, please write up a summary of the IPython-specific things you're doing in this PR, and we'll take that to the IPython guys for input and advice. Until we can get some traction, I'm hesitant to merge this PR. |
|
moving to next milestone. |
|
I get all kinds of errors on |
|
Based on offline conversations, I'm closing this PR for now. The current decision is to make all context usage explicit, and this PR would require a lot of implicit context usage. We can revisit later if necessary. |
3 participants
The array creation routines
fromfunction,zeros,ones,empty, andfromndarray/fromarrayare now in their own module, and not in theContextclass. They use thedistarray.world.WORLDcontext by default, this can be changed by passing them thecontext=kwarg.