Incompatible idioms: relative imports, top-level program file

[Ben Finney]

Ethan Furman <ethan at stoneleaf.us> writes:

> On 02/06/2015 04:44 PM, Ben Finney wrote:
> > A program will often have enough complexity that its implementation
> > occupies several sub-modules. There's no need to explose those in a
> > site package, they normally only need to be local to the
> > application.
>
> If they are not in the Python module path, how are they imported at
> all?

Only absolute imports use the module search path. The whole point of
relative imports is to import a module within the same (or a sub-)
package, without modifying the search path.

    <URL:https://www.python.org/dev/peps/pep-0328/>

> > Python deliberately divorces the top-level module from its package,
> > so it can't access its own relative modules!
>
> My understanding is that imports is for libraries [1], and libraries
> must be in sys.path.

That's the arbitrary limitation I'm pointing out, yes. The program's
private implementation modules should not need to be in the global
module search path, merely to allow the top-level program to import
them.

It's contradictory to present relative imports with the justification
they are for intra-package imports, and then cripple a top-level module
so it can't access its own implementation modules via relative imports.

-- 
 \     “Capitalism is the astounding belief that the most wickedest of |
  `\    men will do the most wickedest of things for the greatest good |
_o__)                               of everyone.” —John Maynard Keynes |
Ben Finney