[Python-3000] u'text' as an alias for 'text'?
"Martin v. Löwis"
martin at v.loewis.de
Thu Mar 20 21:29:24 CET 2008
> 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
More information about the Python-3000
mailing list