Python programs and relative imports

[Rob Gaddi]

Chris Angelico wrote:

> On Sat, Apr 9, 2016 at 2:59 AM, Rob Gaddi
> <rgaddi at highlandtechnology.invalid> wrote:
>> Rob Gaddi wrote:
>>
>>> Does anyone know the history of why relative imports are only available
>>> for packages and not for "programs"?  It certainly complicates life.
>>>
>>
>> Really, no one?  It seems like a fairly obvious thing to have included;
>> all of the reasons that you want to be explicit in saying:
>>
>>   from . import mypkg
>>
>> in a package apply just as well in an executable script.  But instead,
>> they've got different semantics such that you expressly _cannot_ use
>> relative imports in a script.  This feels like such a glaring oversight
>> that there must have been some rationale behind it.
>
> You can use the simple "import mypkg" syntax to load these up. I'm not
> sure what you're looking for - do you want to prevent that syntax from
> working, to prevent accidental shadowing?
>
> ChrisA

Sort of.  If I've got a directory full of files (in a package)
that I'm working on, the relative import semantics change based on
whether I'm one directory up and importing the package or in the same
directory and importing the files locally.  That is to say if I've got:

pkg/
  __init__.py
  a.py
  usedbya.py

then there is no single syntax I can use in a.py that allows me to both
sit in the pkg directory at the shell and poke at things and import pkg
from the higher level.

If the 'from . import usedbya' syntax were always available, then it
would work the same in either context.  And if as I refactored things,
as they moved in and out of packages, it would all still "just work" for
files that haven't moved relative to one another.

But it would also address the accidental shadowing issue.  If you could
use from __future__ import force_relative_imports in an exectable,
then the import semantics would ALWAYS be that "import xxx" looks in
sys.path and "from . import xxx" looks locally.  This is akin to what
the C preprocessor has done for decades by differentiating
  #include <stdio.h>
  #include "localdefs.h"

As is, it's a bit of a hodge podge.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.