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

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

Re: Question about imports and packages

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Question about imports and packages Ben Finney <ben+python@benfinney.id.au> - 2016-05-25 14:39 +1000
    Re: Question about imports and packages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-05-25 18:27 +1000
      Re: Question about imports and packages Chris Angelico <rosuav@gmail.com> - 2016-05-25 18:34 +1000

#109100 — Re: Question about imports and packages

Gerald Britton <gerald.britton@gmail.com> writes:

> On Wed, 25 May 2016 10:00 am, Steven D'Aprano wrote:
> >The problem is that you are running the Python script from *inside*
> >the package. That means, as far as the script can see, there is no
> >longer a package visible -- it cannot see its own outside from the
> >inside.
>
> Thanks for the explanation, Steven. I'm just having trouble
> reconciling this with the docs which seems to imply that an intra
> package import should work from inside the package.

The relative import will work fine inside a package.

The key difference is in *whether* your module is inside that package at
run time.

You have hit upon one of my primary complaints about Python. It makes
this normal mode of running a script::

    python3 ./foo.py

not work properly, because Python in that case has no idea in which
package the module belongs. So it can't import other modules relative to
the current directory.

What the Python import system expects you to do is::

    cd ../
    python3 -m fnord.foo

To me, that makes Python at a *severe* handicap as a simple-to-use
scripting language.

But apparently “address a module by filesystem path” is severely
deprecated in Python. From that follows a lot of problems, such as this
one.


For more on traps with Python's import system, see
<URL:http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html>

-- 
 \       “I cannot be angry at God, in whom I do not believe.” —Simone |
  `\                                                       De Beauvoir |
_o__)                                                                  |
Ben Finney

[toc] | [next] | [standalone]

#109105

On Wednesday 25 May 2016 14:39, Ben Finney wrote:

> What the Python import system expects you to do is::
> 
> cd ../
> python3 -m fnord.foo

I don't think you even need to do the cd provided the fnord directory is inside 
a directory on the path. It only gets complicated if fnord cannot be found by 
the import system.


> To me, that makes Python at a severe handicap as a simple-to-use
> scripting language.

There's something to what you say, but I don't think it's quite that bad. To 
me, "simple to use" means a stand-alone, single file .py file that only imports 
modules in the standard library or site-packages (including the per-user 
directories). So long as your script is a single file, you can always run it 
the old fashioned way:

python /path/to/my/script.py

and it will Just Work.

It's only packages or collections of modules that get tricky, and for them, the 
supported One Obvious Way is to make sure that they are on the PYTHONPATH. To 
make that happen, you are absolutely spoiled for choice:

- if you have root access, you can put them in the global site-packages 
directory;

- otherwise, you can put them in your per-user site directory;

- or you can put them anywhere you like, and point a .pth file to them;

- or add the enclosing directory to your PYTHONPATH;

- or even have your script's main module modify sys.path.


I don't think this is that much different from the way other scripting 
languages handle it. E.g. bash. If I have a set of (say) shell scripts:

fnord/
+-- foo.sh
+-- bar.sh


where foo.sh runs bar.sh, but fnord is *not* on the PATH, the way you make it 
work is:

- have foo.sh temporarily modify the PATH;
- have foo.sh call bar.sh using an absolute pathname.

That second option isn't available to Python, but then, .pth files aren't 
available to the shell :-)


-- 
Steve

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

#109106

On Wed, May 25, 2016 at 6:27 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> I don't think this is that much different from the way other scripting
> languages handle it. E.g. bash. If I have a set of (say) shell scripts:
>
> fnord/
> +-- foo.sh
> +-- bar.sh
>
>
> where foo.sh runs bar.sh, but fnord is *not* on the PATH, the way you make it
> work is:
>
> - have foo.sh temporarily modify the PATH;
> - have foo.sh call bar.sh using an absolute pathname.
>
> That second option isn't available to Python, but then, .pth files aren't
> available to the shell :-)

The one obvious way with shell scripts is a *relative* pathname. You
can say "./bar.sh" (or, if you want to run something relative to the
script directory, some manipulation of path names and $0 will do that
for you). The best Python equivalent would be:

from . import bar

I'd very much like for that to be possible.

ChrisA

[toc] | [prev] | [standalone]

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

csiph-web