> The recommended path for porting Python code to Python 3.0 is to use a > tool called 2to3 to convert the code from Python 2.x code to 3.x code.
Correct. > If you need to support both 2.x and 3.0, you should maintain the code > as 2.x code, and convert it to 3.x code and test it before you make a > new release, and then make two separate releases, one for 2.x and one > for 3.0. You don't necessarily need two separate releases. You could make asingle source release, and have 2to3 run on the user's machines at installation time. > So, there are many people working on the same large set of modules. > All are using direct svn checkouts, because during development of > their product/site they need a module and they discover bugs or add > features to this module. They also have wildly varying experience > levels and python knowledge. In such an environment, you could run 2to3 even at import time, as somebody proposed. > Basically, any sort of code change, no matter how minor, requires a > "change -> test -> copy -> 2to3 -> test" dance, instead of the normal > "change -> test". For the development cycle, it could remain change-test, if the test runner would do the 2to3 conversion first. > The end result of this is that people will not move to Python 3 as > long as they need any sort of third-party product from the Plone > collective or similar set of modules, because it is going to be too > much work. So everybody will stay on 2.x. Which means there is no > incentive to port the third-party products to 3.0. It becomes a > chicken and egg, or a catch 22 problem. I think this problem is highly theoretical. Even if no end-user application is ported to 3.0 within the first year, still: by the time 3.2 is released, all major library packages will be available. > In the best case this means that Python 3 dies and nobody uses it. > Yes, that is the best case. It's a horrible case, I agree. But the > worst case is that the community splits in two, and that will be > dangerous for Python as a whole. Python may survive being split into > two communities, but it would be negative for the community as a > whole. Zope had this problem with Zope 2 and Zope 3. Again, I think these are unfounded fears. > I hope this clarifies things. It does, thanks. I still think you can use 2to3 in all the cases you've described. Regards, Martin _______________________________________________ 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