Re: Non-uniqueness of module names

[Parke <parke.nexus@...>]

On Sat, Apr 20, 2019 at 2:12 PM Sean Conner <sean@conman.org> wrote:
> Okay ... how would you like to see this work?  Also, how do other
> langauges like Python or Ruby handle this?

I don't know how Python handles it, but I remember reading ESR's
criticisms of Python recently.

http://esr.ibiblio.org/?p=8161

-Parke

Excerpt:

The final entry in our trio of tribulations is the dumpster fire that
is Python library paths. This has actually been a continuing problem
since GPSD and has bitten NTPsec pretty hard – it’s a running sore on
our issue tracker, so bad that were’re seriously considering moving
our entire suite of Python client tools to Go just to get shut of it.

The problem is that where on your system you need to put a Python
library module in order so that a Python main program (or other
library) can see it and load it varies in only semi-predictable ways.
By version, yes, but there’s also an obscure distinction between
site-packages, dist-packages, and what for want of any better term
I’ll call root-level modules (no subdirectory under the version
directory) that different distributions and even different application
packages seem to interpret in different and incompatible ways. The
root of the problem seems to be that good practice is under-specified
by the Python dev team.

This is particular hell on project packagers. You don’t know what
version of Python your users will be running, and you don’t know what
the contents of their sys.path (library load path variable). You can’t
know where your install production should put things so the Python
pieces of your code will be able to see each other. About all you can
do is shotgun multiple copies of your library to different plausible
locations and hope one of them intersects with your user’s load path.
And I shall draw a kindly veil over the even greater complications if
you’re shipping C extension modules…

Paralysis around the GIL, the Python 3 strings botch, the library-path
dumpster fire – these are signs of a language that is aging, grubby,
and overgrown. It pains me to say this, because I was a happy Python
fan and advocate for a long time. But the process of learning Go has
shed a harsh light on these deficiencies.