On Thu, Mar 20, 2008 at 7:02 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Lennart Regebro schrieb: > > > On Thu, Mar 20, 2008 at 5:50 PM, Thomas Wouters <[EMAIL PROTECTED]> wrote: > >> It'll do a much better job than try-and-pray. It may not matter in any of > >> your code, but I really suggest not relying on it. Use 2to3. > > > > This is not a case of try and pray, and 2to3 is not a realistic option. > > Can you please try to explain with more words why it is not a > "realistic option"? I still don't get it.
OK, I'll try: 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. 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. That use case works for when you have code that is maintained by a small set of maintainers and regularly released to a large set of users who do not have access to the code repository. That is an ideal situation that isn't always fulfilled, and is a strategy well optimized for those who develop library type modules, but not for others. In many other cases, this is not how code is developed. Both within larger organisations and within large communities like Zope and Plone (and I suspect the same is true for communities such as Turbogears and Django), many people are instead working on the same code base at the same 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. Either all of these people and modules need to switch to 3.0 at the same time, which is unrealistic, or some will run 2.6 and some will run 3.0, and that means that the modules need to support both 2.6 and 3.0. The 2to3 strategy in that case means that everybody that wants to go over to 3.0 needs to have two complete development environments for every instance of the software that they need. Basically, for every website they develop, they would need one instance that runs under 2.6 and one under 3.0. This even though most of the code developed only would run under 3.0 or 2.6, as it's custom for that particular website. The developer would then have to check out the 2.6 code in the 2.6 site, change it there, and test the change, and then run 2to3 copying over the code to the 3.0 instance, and test it there. Basically, any sort of code change, no matter how minor, requires a "change -> test -> copy -> 2to3 -> test" dance, instead of the normal "change -> test". This doubles the effort of making any change. And since testing on the web often means testing with some sort of browser (zope.testbrowser or Selenium or the like) this means restarting a webserver before running the tests. Running tests this was often takes a significant time. 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. 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. So therefore, having so much forwards compatibility in Python 2.6 that we can run a reasonable set of Python code in both 2.6 and 3.0 would be a Very Good Thing. Because that enables us to either make a clean break by running 2to3 once, and dropping 2,x support, or supporting both by writing compatible code (which is a bit of extra effort and will not perhaps not always work) and supporting both by writing 2.6 code and using 2to3 to support 3.0, which is a lot of extra effort, but will work in almost all cases. Now, before we all get into doomsday mode, there is good news. First of all, 2.6a1 already contains a lot of forwards compatibility. And with the "from __future__ import print_function", which adds more such compatibility. The horrible complete compatibility break that we were so worried about might never happen. All that is needed is pretty much a from __future__ import unicode_string_literals, and far as I'm concerned we are all set. And, if we are not, then there is no reason why even more forwards compatibility couldn't be added to a 2.7, if it turns out to be needed. If however people do move over to 3.0 quickly, or to a 2.6/3.0 compatible hybrid, then no more 2.7 additions will be needed. I hope this clarifies things. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 _______________________________________________ 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
