I'm currently wrestling with what the import statements are actually
doing. Removing C means rearranging import statements, which often has
unexpected effects because stuff is installed in C but not yet installed
to all module dictionaries, so C.Expr works because it's executed long
after all import initialization but
import Expr from sympy.core.expr
does not.
There are a few things that I'd like to do to make that easier. I'd like
to hear feedback before I invest substantial time into making these changes.
1. import from the defining module instead of from the standard module
where there is a problem.
E.g. concrete/products.py says
from sympy.polys import quo, roots
but this doesn't always work during module import because these
functions are first defined in submodules, and only later installed into
sympy.polys.
from sympy.polys.polytools import quo
from sympy.polys.polyroots import roots
would work in these cases.
I don't see any problematic ramifications with this, but maybe you guys
do, so I'd like to ask about that change before implementing it on a
large scale.
2. Make it a rule in Sympy implementation code to always import from the
defining module.
Advantages are that import cycles are easier to identify as such,
without having to resort to the full list of install-stuff-to-namespace
activity that Sympy is doing.
Disadvantage is that Sympy itself is becoming less of a useful model for
using Sympy. (But then there's the docstrings so this shouldn't be THAT
problematic... but it's a judgement call.)
One of the reasons I want to do this is that I suspect I won't be able
to find all relevant dependency information unless I do this change first.
Also, I think Sympy coders should really be aware of the dependencies,
just so that they avoid unneeded creating dependency cycles - but that's
ultimately a judgement call, too.
This rule could be enforced by assigning to __builtin__.__import__
during unit tests. The alternate import function would first run the
original __import__, then check whether each imported object is indeed
defined in the given module (that's possible via checking __module__).
3. Use relative imports.
This is a bit of a stylistic issue.
When we're using an import style that's inappropriate for end user code,
this would server as a warning marker so people don't pick up a
needlessly verbose style just because they see it that way in Sympy itself.
As a nice side effect, it would allow moving the Sympy code to a
different name.
E.g. one could have multiple Sympy installations side-by-side and
compare behaviour. Or one could integrate code from different sources
that each insist on a different version of Sympy (assuming that code
uses relative import paths, too).
There might be technical issues with this that I'm not aware of, so
maybe this is a bad idea.
I'd be willing to implement all of this as far as the project is okay
with it.
Thoughts? Comments? Feedback?
Regards,
Jo
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.
