Just to clarify: Python 2.0 was called 2.0 because the BeOpen marketing department thought it was good idea, not because there were major incompatible changes going into that release. Porting code from Python 1.5.2 to 2.0 was relatively straight forward and not much different from other minor releases. The first ever major backwards incompatibility release switch we had in Python after the great renaming of the C APIs between Python 1.1 and 1.2 (which was only visible to C extensions and relatively easy to fix using a compatibility header file), was the transition from Python 2.x to Python 3.x. IMO, the only reason to do this again would be the removal of the GIL, but only if there's absolutely no other way to get around such breakage. I would very much appreciate Python's releases not to introduce such major changes anymore. A continuous gradual change is a lot better to handle than non-continuous breaks and I'm pretty sure both will get us to the same level functionality eventually, perhaps even avoiding a few new mistakes along the way. With that approach, the versioning scheme would just be an implementation detail, which is good. Whether we call it Python 4.2 or Python 42 is really not all that important. Python is mature enough to not have to pull marketing tricks anymore. Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 04 2017)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/