Relative Imports, why the hell is it so hard?

[rocky]

On Mar 23, 11:22 am, CinnamonDonkey <CinnamonDon... at 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... at 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... at pobox.com -http://www.smontanaro.net/
>
>