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

[Ralf W. Grosse-Kunstleve]

Nick Coghlan wrote:

> 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).

The 2.x -> 3.0 transition will be *very* different. We're using Python
since 2000, version 1.5.2. I've always upgraded to the latest release
and got it working with a few fairly minor tweaks. Importantly, I
could do this without breaking backward compatibility if I wanted to.
At some point we had to give up on 1.5.2 compatibility, but that was
just because of Boost.Python requirements (only works with new-style
classes).

IIUC, there is no conservative upgrade path for Python 3.0. Once the
transition is done, the code will only work with 3.0. The bridge to
older Python versions is completely broken. Python 2.x will not even
parse most Python 3 scripts and vice versa. That's a situation we never
had before. Even though the scripts look very similar at face value,
at the parsing level they are as incompatible as e.g. perl and Python.

It is a given that you have to plan for a transition period that is
measured in years: if you have dependencies on 3rd-party packages
(e.g. wxPython) you cannot start using Python 3 until all 3rd-party
packages have gone through the transition. We are using a ton of
3rd-party packages. That's what open source and object-orientation is
all about. The millions of lines of sources that have accumulated over
the years cannot be converted over night. My *optimistic* time horizon
for our project is five years before I can realistically think of
giving up on Python 2, and start *a few weeks of work* to push all
our stuff over to Python 3. During that time, all serious development
work will have to be postponed.

My pessimistic time horizon is "forever". Python 3 has the potential
to become the software version of the Itanium if the deployment isn't
handled carefully. Worse, it could even reflect badly on Python 2
if the naive user just knows that "python script" usually ends in a
syntax error unless he thinks twice about what machine he is using
to run which script.

As Python developers you have to realize that for many people Python is
"just" a core around which they build much bigger applications. If the
success of Python is to continue, you have to give your large user
base a clear path to working with two co-existing Python versions,
so that installing a Python 3 application doesn't break all Python 2
applications (some of which may never be converted since the original
developers have moved on). For example, I really need to be able
to use wxPython based on Python 2 and wxPython based on Python 3
simultaneously on my Windows machine. I'm thinking this is only
possible if Python 3 uses a new file extension.

Ideally, I'd even want to have both Python 2 and Python 3 scripts in
the same directory, while incrementally converting our applications.
I'd want to cp script.py script.py3, then edit the .py3 version
until it works, while still being able to run the old version during
the migration period. Of course, I could also start a new Python 3
specific directory structure, but then I'd have to jump back and
forth between two complex trees all the time, which is very annoying
and time consuming; and I may have to copy many non-Python files that
I wouldn't have to maintain in two copies otherwise.

I think it will be essential to give the Python 3 interpreter a new
name and the scripts a new extension. I suggest using "py3" for both.

Ralf