[Python-3000] Namespaces are one honking great idea -- let's do more of those!

[Stephen J. Turnbull]

Mike Meyer writes:

 > Personally, I think *this* [proposal to link 2.x to 2.y for y < x]
 > is a crock. But if you're going to advocate that people lie about
 > what versions they have installed,

If you insist on that interpretation, consider that it's no different
from the common cc -> gcc link.  Anyway, your favored solution of
"python2" tells exactly the same "lie" ("Python 2" is not installed!),
but in a way that cannot be interpreted satisfactorily for as many
apps that have specific version preferences without changing the apps.
Also, it doesn't tell what version of Python is actually recommended
by the developers, which is a potential support issue.  Finally, the
developers who use "python2" shebangs *are* lying (no quotes!) unless
they use only features present in Python 2.0.

You asked whether I oppose making things easy.  Not everything, but I
sure do oppose making such inaccuracy easy!

As I interpret it, in my proposal you aren't telling anyone that you
have that version of Python installed; you are telling applications
that you have installed *some* version of Python that can handle that
version of the API.  Eg, an admin can determine which Python version
will deal with "python2.2" simply by doing "ls -l `which python2.2`".

Again, it's not correct to interpret "python2" that way; "python2" is
the sysadmin's preferred version of Python 2 at the moment, which in
my experience is unlikly to be 2.x.0 for any x, and might be
substantially older if the mission-critical apps run satisfactorily on
that older version.  Implying that "'python2' can handle any Python 2
script" is likely to remain a lie until the release of 2.x.1 at least,
and possibly indefinitely.

 > With python2, [if there's a problem with 2.x's initial release] you
 > set the python2 link back to the previous version. Yeah, you may
 > have to fix the apps that require the new version,

Which is (a) unnecessary in my scheme and (b) a long-term maintenance
burden when upgrading the apps that require the new version.  The
second is a serious annoyance in my experience.

 > Personally, I think that's a *lot* easier than running around creating
 > or re-creating a bunch of symlinks every time I install or upgrade
 > python,

Huh?  Eminently automatable.  Why do you think it would be hard?

Also, do you really install or upgrade Python more often than you
install or upgrade apps that run on Python, each time risking annoying
breakage that requires hacking the app to fix?  And since the app may
not even tell you which versions you already have available that might
be satisfactory, you have to test them yourself, and possibly install
and uninstall several versions!

Finally, do you really uninstall old versions that often?  It seems
likely to me that there probably would be no need at all to fiddle
with symlinks based on upgrading Python 2.4.3 to Python 2.4.4, and no
*pressing* need to update the symlinks upon installing Python 2.5.1
alongside Python 2.4.4.  Rather you'd do that at a later time, after
Python 2.5 "shakes down" and you've tested all your important apps
with 2.5.

Yes, it's a matter of balance, and YMMV.  But between the theoretical
deficiencies of "python2" and the degree to which I believe you're
exaggerating the frequency (or lack thereof) that you would encounter
the relevant situations under the two plans, I really don't see a good
argument for "python2".

 > much less trying to figure out when I really can declare that
 > I no longer need some version under those conditions.

This is a real issue with the scheme I proposed, although modern
versions of file will tell you the whole shebang, I think.  It's also
a problem that modern PMSes will help you with, as well as being one
faced only by those who run an unusually tight ship in my experience.
Again, I would imagine it's not hard to automate.

 > On the other hand, if setup.py made setting up the symlinks easy,
 > maybe I'd change my mind.

I think this should be a separate tool, but either way I'd not object
to making it easy to do, as long as it was not default.