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 _______________________________________________ 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