On Mon, Oct 7, 2013 at 7:35 PM, Joachim Durchholz <[email protected]> wrote:
> Am 08.10.2013 00:37, schrieb Aaron Meurer:
>
>> On Mon, Oct 7, 2013 at 11:33 AM, Joachim Durchholz <[email protected]>
>> 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.
Python 2.6.8.
My setup was
test1:
__init__.py
testfile1.py
test2:
__init__.py
testfile2.py
The contents of the files are
test1/__init__.py:
from .test2 import *
from .testfile import *
testfile1.py:
name = 1
test1/test2/__init__.py:
from .testfile2 import *
testfile2.py:
from ..testfile import name
I then ran (from the directory containing test1):
>>> import test1
>>> test1.test2.testfile2.name
1
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__)
>
>
>> 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.
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).
>
> 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.
Reordering alphabetically is fine, but I wouldn't expect it to stay
that way. I personally have my text editor set to highlight pyflakes
errors and warnings, so I know right away when I do something like
this. I also personally always add imports to the end of the list. I
try to keep the lines in order, but not the imported names.
By the way, pyflakes will also tell you about a ton of unused imports.
Getting rid of those can't hurt either.
Aaron Meurer
>
>
> --
> 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.
