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

[Mike Meyer]

On Wed, 06 Feb 2008 21:09:11 +1000 Nick Coghlan <ncoghlan at gmail.com> wrote:
> Mike Meyer wrote:
> > On Wed, 06 Feb 2008 01:01:05 +1000 Nick Coghlan <ncoghlan at gmail.com> wrote:
> >> While I'm +1 on the idea of making altinstall the default for setup.py 
> >> and the Windows installer (forcing the administrator to explicitly 
> >> request that the new Python version be made the default Python 
> >> installation for the machine), I'm a pretty strong -1 on officially 
> >> blessing the idea of a python3 alias or a special py3 extension on 
> >> Windows (end users are obviously free to create those if they want, of 
> >> course).
> > I like the python3 alias (and python2 in 2.X), because it moves us
> > from a single default python to having a default python2 and python3,
> > which means scripts that care can ask for that without breaking the
> > ability to upgrade python2 or python3 without breaking those scripts,
> > while still allowing the default python to be either python2 or
> > python3.
> The main objection I have is that the executable name is only part of 
> the story - all of the PYTHON* environment variables may matter as well 
> (there are 9 listed in python -h, and I would have to check the code to 
> say with complete confidence that there aren't any others).

True, there are 9 of them, but most of them are version-neutral, in
that they change the behavior of python in some way, but *not* what
scripts it finds. While you may want different versions of them for
different python versions, 2 vs. 3 doesn't seem to be a factor (unless
it ignores them and uses others):

PYTHONOPTIMIZE, PYTHONDEBUG, PYTHONINSPECT, PYTHONUNBUFFERED, PYTHONVERBOSE
and PYTHONY2K

For that matter, all but PYTHON2K are an alternative to a command line
option. I think we can safely ignore all of them. That leaves:

PYTHONHOME - this tells python where to find it's standard
libraries. Setting it is bad for your health and sanity unless you
*really* know what you're doing. I think we can safely ignore it.

PYTHONSTARTUP - generally only set per user, and only for interactive
pythons. Anyone with the chops to set this up can make it work for
both by checking the version and importing an appropriate
version-specific module.

PYTHONPATH - this one is the real issue. It's used by people who can't
write to python library to point add third party modules to the
standard path. Personally, I tend to install Python (after all, if I
can install the modules, I can almost certainly install python) in
that case, but that doesn't help them. If they have both installed on
the system and can't write to their libraries, something has to be
done to deal with it.

> That said, while as a matter of purity I still think this is a platform 
> problem (one which all current platforms I know of handle poorly ;), as 
> a matter of practicality I'm seeing some benefits allowing a machine to 
> have full fledged "Python 2" and "Python 3" setups side by side.
> 
> If Guido does decide to go the route of changing the interpreter binary 
> to python3 (ala sqlite vs sqlite3), I would also suggest that we go the 
> whole way and insert a '3' into all of the environment variable names 
> that python3 looks for (PYTHON3PATH, PYTHON3STARTUP, etc). I'd even 
> concede the utility of accepting the py3 extension on modules as a 
> concession to extension based dispatching on Windows.

Actually, you can get that kind of behavior by using shell scripts
instead of symlinks for  python2 and python3 commands:

#!/bin/sh
PYTHONPATH=${PYTHON2PATH:-$PYTHONPATH} /usr/bin/python2.6

and similarly

#!/bin/sh
PYTHONPATH=${PYTHON3PATH:-$PYTHONPATH} /usr/bin/python3.0

Except you can't use #!/usr/bin/python2 in this case; you have to use
#!/usr/bin/env python2, which might be a problem.

> I still think it would be a bit of an ugly hack, but if it was followed 
> through to the point of being able to define separate Python 2 & 3 
> environments without the use of launch scripts (i.e. by changing the 
> environment variable names as described above), maybe it would still be 
> a worthwhile thing to do.

How about if we hide the "launch scripts" in the python2 and python3
commands, as above?

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