Incompatible idioms: relative imports, top-level program file

[Rustom Mody]

On Saturday, February 7, 2015 at 7:35:12 AM UTC+5:30, Ben Finney wrote:
> Ethan Furman  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.

Thanks Ben for these points.

We techies need to always slide the rheostat along:

1. I am dumb
2. I am ignorant - need to read up some
3. Stuff is complex - more to read up
4. Stuff is complicated - after all the reading up, some general ideas may 
get clear but there remain all sorts of dark nooks and crannies
5. Stuff is a complete bloody mess - anyone who claims to understand, doesn't understand and doesn't understand that he doesn't understand.
[Think Stroustrup saying something to the effect it takes a lifetime to learn C++ !]

Your points and the earlier thread have helped me to slide the rheostat a 
couple of notches down!

My analysis of the problem:

Python docs are a model of clarity... mostly.
They fail when the rubber hits the road - OS-specific stuff.

In the attempt at keeping the docs generic, when things like how the 'insides'
of python map to the 'outsides' - file-system-mapping - I find the docs are sorely inadequate. [You are of course free to slide my rheostat up :-) ]

There is on the one hand python modules/packages mechanism with all the 
hell of dozens of incompatible versions of setuptools/distribute/distutils etc.

On the other there is the OS-specific practices/policy such as
https://www.debian.org/doc/packaging-manuals/python-policy/

And the dark unexplored territory in between.
[Its a research project to figure out clashes between pip and apt]

Hopefully python-devs will give up trying to be generic in this area and start
documenting these things in an OS-specific way.

Yeah I know it can be significantly more of a babel than just:
Windows - This-a-way
Linux - That-a-way

eg:
- Mismatch between say Fedora and Debian
- Different 32-64 bit path-disambiguation on different windows systems
- etc

Still... we need to bite the bullet

Since this has been somewhat of a rant I should say:
Wherever comparable to python we may look, its just like this or worse.

Perl/Ruby are probably slightly more mature
Haskell is much worse - search for "cabal hell" 
Latex is probably about the same: eg a debian texlive bugreport of mine:
https://lists.debian.org/debian-tex-maint/2014/06/msg00029.html
followed by unhelpful/improper response of the debian-dev