[Python-3000] u'text' as an alias for 'text'?

Lennart Regebro regebro at gmail.com
Thu Mar 20 20:51:04 CET 2008


On Thu, Mar 20, 2008 at 7:02 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> Lennart Regebro schrieb:
>
> > On Thu, Mar 20, 2008 at 5:50 PM, Thomas Wouters <thomas at python.org> 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


More information about the Python-3000 mailing list