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

[Nick Coghlan]

Guido van Rossum wrote:
> This should be brought up on the python-3000 list; I'm moving it there
> using a Bcc to python-ideas.
> 
> To some extent it is up to the vendors who distribute binaries -- they
> decide what to call it.
> 
> Perhaps we should only install "python3.0" and not "python". That is a
> valid choice already and always has been (python2.1, python2.2, etc.
> are always installed by default, "python" is just a convenient alias).
> 
> I think that worries about Python becoming the laughingstock of the
> language world are highly exaggerated. The post you refer to sounds to
> me like the typical cynical one-liner from someone who doesn't really
> care, not about a position of someone who is influential in the world
> of language users.

I personally haven't seen anything to convince me that the 2.x -> 3.0 
upgrade cycle is going to be significantly worse from a deployment point 
of view than a 2.x -> 2.(x+2) upgrade cycle where breakages are also 
possible (e.g. code using 'with' or 'as' as identifiers runs just fine 
on 2.4 or 2.5, but that code is going to break in 2.6).

Yes, the breakages in 3.0 are more significant and more widespread, but 
the tools to support migration and the time allowed for migration are 
correspondingly increased. I would also expect nearly all systems to 
stay with a 2.x release as the default python at least until after 3.1 
comes out.

The only question is what to do about applications that want to declare 
themselves as python 3 applications so that the platform knows how to 
handle them correctly, but also want to fail gracefully if someone tries 
to run them with the wrong version. And really, that problem already 
exists for 2.x applications that require a certain minimum version (e.g. 
if you use with statements or conditional expressions in your main 
module, even with a future statement, then it will fail to compile on 
all versions prior to 2.5).

I think the general solution is the same in all such cases: the affected 
application or library (not the language) should include a short and 
simple entry point module that uses the bare minimum amount of code 
needed to ensure the correct runtime environment. Something like:

import sys
REQUIRED_VERSION = (3, 0, 0)
if sys.version_info < REQUIRED_VERSION:
   sys.exit("Require Python version %d.%d.%d, using version %d.%d.%d"
            % (REQUIRED_VERSION + sys.version_info[:3]))
import real_main
real_main.main()

For environments where the default version of Python doesn't meet the 
application's requirements, then it will be up to the owner of that 
environment to work out how to get that specific application to run with 
the correct version (e.g. add a python3 alias and modify the main 
script's shebang line or use a wrapper script or GUI shortcut that 
explicitly invokes the correct python version).

Actually adding a python3 alias as part of the default py3k installation 
would bother me a little, as we'd then be stuck with providing it for 
the life of the 3.x series - adding cruft while trying to remove it 
seems like a backwards step.

And for in-house development, web-based applications or embedded devices 
where the developers have control of the run-time environment as well as 
the application code, then there is absolutely no problem at all, as the 
system will be configured to use the right version of the interpreter no 
matter which version it happens to be.

Cheers,
Nick.

P.S. Good thing we decided to keep string mod-formatting despite the 
addition of the format method ;)

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org