[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