Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #106458 > unrolled thread

Python programs and relative imports

Back to article view | Back to comp.lang.python

Contents

  Python programs and relative imports Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-04-04 17:07 +0000
    Re: Python programs and relative imports Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-04-08 16:59 +0000
      Re: Python programs and relative imports Chris Angelico <rosuav@gmail.com> - 2016-04-09 03:11 +1000
        Re: Python programs and relative imports Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-04-08 17:50 +0000
          Re: Python programs and relative imports Chris Angelico <rosuav@gmail.com> - 2016-04-09 04:04 +1000
          Re: Python programs and relative imports Ian Kelly <ian.g.kelly@gmail.com> - 2016-04-08 12:26 -0600

#106458 — Python programs and relative imports

Does anyone know the history of why relative imports are only available
for packages and not for "programs"?  It certainly complicates life.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com

Email address domain is currently out of order.  See above to fix.

[toc] | [next] | [standalone]

#106692

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.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com

Email address domain is currently out of order.  See above to fix.

[toc] | [prev] | [next] | [standalone]

#106694

On Sat, Apr 9, 2016 at 2:59 AM, Rob Gaddi
<rgaddi@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

[toc] | [prev] | [next] | [standalone]

#106700

Chris Angelico wrote:

> On Sat, Apr 9, 2016 at 2:59 AM, Rob Gaddi
> <rgaddi@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.

[toc] | [prev] | [next] | [standalone]

#106702

On Sat, Apr 9, 2016 at 3:50 AM, Rob Gaddi
<rgaddi@highlandtechnology.invalid> wrote:
> 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.

Ah, I see what you mean. You're working inside an actual package here.
So you can "cd ..; python3 -m pkg.a", or you can "python3 a.py", but
not both.

The simplest fix for that would be to allow "python3 -m .a" to mean
"current directory is a package". I don't think there's currently a
way to spell that, but it ought to be completely backward compatible.
You could raise this on python-ideas and see what people say.

ChrisA

[toc] | [prev] | [next] | [standalone]

#106707

On Fri, Apr 8, 2016 at 11:50 AM, Rob Gaddi
<rgaddi@highlandtechnology.invalid> wrote:
> 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.

Not necessarily. Inside the package, 'from . import usedbya' is
effectively equivalent to 'import pkg.usedbya as usedbya'. Without the
package, all of these modules are at the top level, and 'from . import
usedbya' would conceptually be equivalent to 'import usedbya'. But
there's no guarantee that the 'usedbya' module at the top level of the
module tree is the same 'usedbya.py' file in the current directory; it
could be shadowed by some other module. Whereas with the package, the
packaging ensures that you'll get the module expect.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web