MAINT: delay initialization of getlimits (circular imports) #12064
Conversation
|
This works. I wonder if there is another way that keeps things together that hasn't occurred to us. @eric-wieser Thoughts? This sort of thing isn't unique, ISTR that there are other places where import order is important. |
|
Go to close/open this to experiment with azure. |
|
I'm not particularly happy with this, it seems messy :( But I'll put it in if noone can suggest a better approach. I assume that the problem cannot be fixed by changing import order? Could the package be moved? |
getlimits previously called numpy code before all of numpy was loaded, which often causes circular import issues. This delays getlimits init. Fixes numpy#12063
589ef4c to
699dfee
Compare
|
Can modules in core be moved? Currently people can import it as I agree it's ugly. I just added a commit trying to make it more palatable by removing all the global variable declarations and underscores, other ideas welcome. I can drop the commit if you like the old commit better. |
|
Thinking about this, it does seem to me that execution of |
|
Thanks Allan, let's get this in. I wonder if we should pull most of this into the init file itself? I think we could drop the fallback code and just raise an error for unrecognized types. |
During module initialization, getlimits.py previously called numpy code before all of numpy was loaded,
which often causes circular import issues. This PR delays getlimits init.
This partly reverts and also continues PR #9113. Here, I made the whole of getlimits delay initialization. It's not good for any numpy code at all to be run before numpy is fully loaded.
Fixes #12063