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 -- https://mail.python.org/mailman/listinfo/python-list