On Thu, Jul 18, 2013 at 9:05 AM, Joachim Durchholz <[email protected]> wrote: > 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.
Probably because that's not valid syntax :) > > 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. If this works, then do it. The only issue is that it makes it more annoying when people move functions around. For the most part in SymPy, if you can "from sympy import something", then it is not worth it to "from sympy.module.submodule import something" because pretty much every submodule will do a complete import of SymPy anyway. There may be performance issues with this, but you'd have to profile to find out (I'm not even sure which one should be faster, "from sympy import something" or "from sympy.module.submodule import something"). > > > 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__). I'm not convinced this would solve all the circular import issues, though. > > > 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. Actually, now that we have dropped Python 2.5 support, we can do "from __future__ import absolute_import" and use either absolute imports or .. style relative imports everywhere. I think we should do this, because it removes issues that people sometimes have with things like having a file named numbers.py that SymPy thinks is sympy.core.numbers. > > > I'd be willing to implement all of this as far as the project is okay with > it. I thought that most C uses could be solved by moving imports inside functions. This may have performance issues, but we should profile that. We may also have to reorganize certain class attributes to be properties (which they usually should be anyway, and it will make import time faster, like at https://github.com/asmeurer/sympy/commit/ae51bce37847fa7f5c909bd3865d19fd61542ea7). Aaron Meurer > > 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. > > -- 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.
