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


Groups > comp.lang.python > #80571

Re: Python modules

From Ben Finney <ben+python@benfinney.id.au>
Subject Re: Python modules
Date 2014-11-12 09:18 +1100
References <i0h06a9pj8h3olo5rnrgc64i7ckpvtvti6@4ax.com> <e59e1214-b867-4e7b-9d31-fb8c2efd5d40@googlegroups.com>
Newsgroups comp.lang.python
Message-ID <mailman.15696.1415744348.18130.python-list@python.org> (permalink)

Show all headers | View raw


Will Acheson <willyach07@gmail.com> writes:


> I have had a lot of trouble with executing relative imports with some
> of my projects in python.
>
> Are there any best practices or methods besides '../../' type
> hard-coding?

The important point to learn with Python's import system, as contrasted
with various other languages, is that it is *intentionally* abstracted
from the filesystem hierarchy.

That allows all kinds of helpful infrastructure, but it also comes with
the cost of learning how to let Python know where modules are to be
imported from; it's not a simple case of stating filesystem locations.

The point which tripped me up for a long time, and which I have to keep
reminding myself of:


Python looks for modules in its import search path. Corollary: structure
your project into a hierarchy of packages, including the top level, and
specify all relative imports starting at that top-level package.


Often the cause of my intra-project import woes comes from having
several *discrete* packages, but trying to do relative imports between
them::

    hurgen/            # Note: ‘hurgen’ is not a Python package.
        foo/
            __init__.py
            spam.py
            beans.py
        bar/
            __init__.py
            eggs.py
            ham.py

This is a poor structure, because Python needs to be told about each of
‘foo’ and ‘bar’ separately if relative imports are to work. Worse, a
module invoked as the top-level module (e.g. ‘eggs.py’) can't do imports
relative to itself, because it isn't even aware it's in a package!

Better is to structure the project explicitly under a top-level named
Python package::

    hurgen/
        __init__.py
        foo/
            __init__.py
            spam.py
            beans.py
        bar/
            __init__.py
            eggs.py
            ham.py

and import all the project's modules relative to the ‘hurgen’ package.

Back to comp.lang.python | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

Python modules Steve Hayes <hayesstw@telkomsa.net> - 2014-11-10 06:55 +0200
  Re: Python modules Deepfriedice <Deepfriedice@openmailbox.org> - 2014-11-10 14:55 +1000
  Re: Python modules Ben Finney <ben+python@benfinney.id.au> - 2014-11-10 16:12 +1100
    Re: Python modules Steve Hayes <hayesstw@telkomsa.net> - 2014-11-10 08:58 +0200
      Re: Python modules Ben Finney <ben+python@benfinney.id.au> - 2014-11-10 18:48 +1100
  Re: Python modules Roy Smith <roy@panix.com> - 2014-11-10 08:36 -0500
    Re: Python modules Chris Angelico <rosuav@gmail.com> - 2014-11-11 00:49 +1100
  Re: Python modules Will Acheson <willyach07@gmail.com> - 2014-11-11 12:06 -0800
    Re: Python modules Ben Finney <ben+python@benfinney.id.au> - 2014-11-12 09:18 +1100

csiph-web