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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
