On Mar 23, 11:22 am, CinnamonDonkey <cinnamondon...@googlemail.com> wrote: > Hi Guys, > > Thanx for the quick responses, it is very much appreciated! > > Skip, that's a good point about "C++ != Python" and I assure you I am > very much aware of that ;-). > > Looking athttp://www.python.org/dev/peps/pep-0328/#guido-s-decision > would suggest, unless I am completely miss-understanding the example, > that '.' refers to the current level and '..' pops up a level. First > three uses: > > # Access moduleY in same level as ModuleX > from .moduleY import spam > from .moduleY import spam as ham > from . import moduleY > > Just to be sure though I tried both ;): > > from ..subpack2 import module1 #ValueError: Attempted relative import > beyond toplevel package > from .subpack2 import module1 #ImportError: No module named subpack2 > from . import subpack2 #ImportError: cannot import name subpack2 > from .. import subpack2 #ValueError: Attempted relative import beyond > toplevel package > > Max, thank you for the response... I tried adding "from __future__ > import absolute_import" which made no difference. I still get exactly > the same error messages. Perhaps I should have mentioned that I am > using Python 2.5, which I understand alread supports relative imports > out of the box. I'll keep this line in for now anyway though :-) > Cheers!
I wrote http://code.google.com/p/pyimport-relative so I could have a simple and more reliable way to specify a *file* relative import in Python 2.5 (and it works with 2.6 as well). I'm not sure it's for everyone, or that it is flawless. Actually, it's not. But I use it for in pydbgr (http://code.google.com/p/pydbgr) so see that for examples of how to use. It allows me to run the development code out of the source tree while having possibly a different version installed as an egg. > > #subpack1.module1 > from __future__ import absolute_import > > from .. import subpack2 > > def subpack1_module1_foo(): > print "subpack1_module1_foo()" > call_subpack2_module1() > > def call_subpack2_module1(): > subpack2.module2.subpack2_module2_foo() > > #subpack2.module2 > def subpack2_module2_foo(): > print "subpack2_module2_foo()" > > #main.py > import subpack1.module1 > > if __name__ == "__main__": > subpack1.module1.subpack1_module1_foo() > > I am starting the sandbox app with the command line: python main.py > with the current working directory in \app where main.py is located. > > Shaun >8) > > On 23 Mar, 14:44, s...@pobox.com wrote: > > > >> Please, please... please! don't go off on rants about why you think > > >> relative imports should not be used. I've got 15+ years in C++ and > > >> relative inclusion of other sections of code has never been a > > >> problem. As far as I am concerned what I am trying to do is > > >> perfectly reasonable and valid. > > > However, C++ != Python. Regardless whether or not you can "make it work", > > translating idioms from one language to another is often suboptimal. That > > may not be the case here, but it bears keeping in mind. > > > >> Example: > > > >> \ App > > >> | main.py > > >> +--\subpack1 > > >> | | __init__.py > > >> | | module1.py > > >> | > > >> +--\subpack2 > > >> | | __init__.py > > >> | | module2.py > > > >> Module1 needs to access functionality in Module2. > > > >> #module1.py > > >> from ..subpack2 import module2 > > > >> Seems reasonable to me... but it just does not work and I was so > > >> liking Python. :( > > > You might try removing a dot from your import statement. Python is also not > > Unix. Popping up one level in the package hierarchy is done with ".", not > > "..". > > > -- > > Skip Montanaro - s...@pobox.com -http://www.smontanaro.net/ > > -- http://mail.python.org/mailman/listinfo/python-list
