The most important thing first, it got sidetracked:
Should I go ahead and resolve all "from sympy import" clauses to go to
the exporting module directly?
I'll want to use absolute imports first, I wouldn't want to do two
potentially troublesome changes at the same time; the switch to relative
imports would be a second task.
Am 08.10.2013 04:09, schrieb Aaron Meurer:
So it looks like the .. import in testfile2 worked.
But if you can give an explicit example where it does fail, it
wouldn't surprise me. Just commit the changes to some dummy branch in
git. There are a lot of aspects to imports that my example doesn't
cover (like non-trivial import graphs, or __all__)
Unfortunately I didn't take notes of the exact circumstances where it
would fail.
It might be related to the way unit tests are set up, particularly in
the --no-subprocess case. Could be something else entirely.
I'll give it another try once I get around to relative imports.
So here's my plan, in three steps that will become separate pull requests:
1) Resolve all the "from sympy import" clauses as "from
sympy.module.submodule import".
JUST FOR SYMPY AND ITS UNIT TESTS. Docstrings, doctests, and .rst files stay
as they are.
Relative imports stay as they are.
The test suite could become faster as a result - if each test file actually
runs the full sympy.__init__ (I suspect they do). Not a huge deal but might
help anyway.
The __init__.py is run once when sympy is first imported. After that,
any imports are basically cost-free, because it caches the module in
sys.modules and all names on it are just a dictionary lookup (roughly
as costly as using a variable in your own namespace).
Each unit test file is run in its own clean environment. With
--no-subprocess, the test code sets up a clean environment, reads,
compiles and runs the test file. Without that option, it does something
pexec-like.
My assumption is that the import statement will find an empty namespace
and reimport sympy.
I haven't checked details, I noticed these things in passing when I was
after other issues. So I might have misunderstood things or missed
relevant details.
This doesn't matter much. sympy is imported once per test file at most,
and while the import does take a few seconds, the real testing overhead
is elsewhere.
2) Revisit the relative imports issue. Check which, if any, Python versions
are affected; see whether the various test modes are affected.
3) Reorder the imports alphabetically so that duplicates become easier to
detect. (I spotted a duplicate import recently - the same function had an
absolute import and one from the sympy namespace.)
pyflakes will also find these for you.
Eclipse does as well.
The use case was coders who don't use static analysis.
I also personally always add imports to the end of the list.
I'd suggest keeping these sorted as well.
An unsorted list is really hard to follow if you're analyzing code manually.
By the way, pyflakes will also tell you about a ton of unused imports.
Getting rid of those can't hurt either.
I'll remove these as I see them.
--
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.
