[Python-Dev] Proposal: from __future__ import unicode_string_literals

["Martin v. Löwis"]

> Nuxeo CPS worked like this, but we can ignore them as that project is
> all but dead will never move to Python 3 in any case. Zope/CMF/Plone
> works like this.

I don't understand. AFAICT, Zope *is* a library, i.e. you have to run
setup.py for lots of packages. Do you not have to run setup.py, for,
say, zope.interface, or zope.psycopgda?

It's fine that all people develop on the same subversion repository.
Doing so integrates nicely with 2to3.

> The Plone collective works like this, and it is *not*
> reasonably well managed, so there software quite often doens't get
> released, but people run against trunk.

And that's fine. You still can integrate 2to3 with that transparently.

> I know Django people both
> strive to support multiple versions of Python and regularily run their
> production sites on trunk. Insane, perhaps, but that's how things are.

And no need to change that, see

http://wiki.python.org/moin/PortingDjangoTo3k

Just to repeat myself: With that patch to Django, you can
a) support all versions of Python simultaneously, from 2.x to 3.0
b) work from the subversion trunk all the time
c) transparently invoke 2to3 on the trunk; you won't even notice
   that you do (except for all the diffs it currently prints to
   stdout also :-)

FWIW, your approach (of adding __future__ imports to 2.6) wouldn't
help Django at all, as they would need to give up 2.5 and earlier.

> So, in short: Large projects with interconnected modules where the
> developers and users of module are the same people will have big
> difficulties with the 2to3 approach and would be the people who are
> most likely to not be able to in practice go forward to Python 3
> unless they have some sort of smooth path forward.

I still don't see why that is. In the examples you gave, no such
difficulties are apparent.

Regards,
Martin