Am 08.10.2013 00:37, schrieb Aaron Meurer:
On Mon, Oct 7, 2013 at 11:33 AM, Joachim Durchholz <j...@durchholz.org> wrote:
I'm currently running into problems with imports.
Problem 1: Relative imports don't work in 2.6.
"from .module import blah" works, but "from ..module import blah" does not.
Really? I don't see any mention of this in the docs.
I think one of the Python release notes carries a reference that this
got fixed (or, rather, the original semantics appropriately extended).
I'll have to double-check though.
I did a little test of this and it seems to work for me.
What Python version did you test?
Also, there were some issues with contexts.
And, single-dot imports worked just fine for me, it was the double-dot
and more ones that gave me trouble.
> So are you
sure you weren't really running into another issue.
Mmm... yes, it might actually be related to setting up the module
context inside the tests.
> Unfortunately,
when it comes to imports, Python's error messages are really bad
(e.g., when there is a circular import problem, it will just say
"ImportError: could not import x", which is the exact same error
message you get when x never existed in the first place).
Oh dear.
But no, it was not a circularity or unavailability problem, replacing
the relative import with an absolute one fixed the problem.
At which point I gave up on introducing relative imports.
That's really a pity, I'd be all for doing all imports in a relative
fashion, but if 2.6 doesn't support it, I'd suggest going back to absolute
imports.
SUGGESTION:
Postpone using relative imports until we drop the last Python version that
does not support them fully.
Problem 2: Most Sympy modules do most of their imports through
"from sympy import blah", and don't care what those modules come from.
This is fragile because whether a "from sympy" import will work depends on
whether you're inside an __init__ module or not, and if there, whether the
code of the module defining "blah" has already run or not.
I.e. you can't reorder import statements freely due to implementation
details inside the imported modules.
SUGGESTION:
Eliminate the use of "from sympy import" /inside SymPy itself/.
User code and example code should still use "from sympy import".
I agree, if this helps avoid circular imports, though it's less
convenient to write, and annoying when you want to move functions
around. I also agree that we should keep user code as "from sympy
import", because although we do consider importable names as part of
the API, their locations are implementation details
+1.
> (i.e., I don't
want to create a deprecation warning every time we want to refactor
some submodules).
Heh. I can imagine.
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.
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.)
--
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 sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.
