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

[Mike Meyer]

On Mon, 04 Feb 2008 20:22:04 +0900 "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> Marcin ___Qrczak___ Kowalczyk writes:
>  > Dnia 03-02-2008, N o godzinie 10:24 +0900, Stephen J. Turnbull pisze:
>  > > I don't see any need to shorten "python3.0" to "python3".
>  > There is a need. Using #!/usr/bin/python3.0 would break as soon as
>  > python3.1 is released, while #!/usr/bin/python3 would be fine, at
>  > least in the next few years.
> First of all, under current policy, installing Python 3.1 would not
> uninstall or overwrite Python 3.0

Wrong. The recommend "make install" overwrites the "python" link.

> so nothing "breaks" when the user uses #!/usr/bin/python3.0.

Unless, of course, the user used their systems packaging software to
upgrade the default python install, and that's been moved to the newer
version. In that case, every packaging system I've ever used will
remove the old version, thus breaking any scripts that were foolish
enough to use that form.

Which is why those packaging systems pretty much all install python
scripts using "python" for the executable.

> On the contrary, Python 3.1 itself may be buggy.  I do not think is
> it appropriate for the Python installer to make that decision for
> the user by creating a link to the most recent python3.x.

Except it currently does, both during the install from source *and* as
installed by most packaging systems. If the packaging system does
things right, this isn't really a problem - until you get to 3.0,
because it breaks backwards compatibility.

> What I see no need for is a policy statement *by Python* that there
> "should" be a "python3" link, or which python3.x is should point to.

So do you think we should do away with the "python" link as well?

> I don't think that Python providing a simple tool to help the user do
> it is a good idea, either, because most OS distributions already
> provide them, and they tend to be rather obnoxious about "rogue" users
> who do it by hand or use 3d party (including upstream) tools to do it.

The reason OS distributions are hard on "rogue" users who change the
meaning of "python" is because their system tools quit working when
you do that, as they all use "python". So when they start shipping
python3, they'll tend to make "python" invoke the old version until
they convert all their scrips, as RH did with 1 and 2. Except RH still
has a python2 alias, so they can easily switch their scripts to
python2 if they chose to do so. Personally, I'd rather they do the
latter than the former, so people will get a modern version of python
when they ask for python on that OS.

Most of the time, having a default for both python and python of a
specific major version is pointless, because you're only going to have
one major version installed, even if you have multiple minor versions
installed, so they're both the same. The exception is when a new major
version arrives breaking backwards compatibility. At that time, it's
nice to have a default for the major versions so scripts can pick the
major version if they're not picky about minor versions (and given how
much work we do making sure the language is backwards compatible at
that level, there are a lot of those) at the same time as users pick
what they want to get when they say "python".

Having the python install provide the major version link as well as
the versionless "python" link means it becomes reasonable to
distribute scripts that use link, because most installs will have
it. It encourages vendors to use that link in their system-specific
scripts, so they can provide a backwards-incompatible version of
python, and make "python" invoke it for users. Both of these are good
things.

	<mike

-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.