[Python-Dev] PEP 414 - Unicode Literals for Python 3 (original) (raw)

Giampaolo Rodolà g.rodola at gmail.com
Tue Feb 28 16:30:58 CET 2012

Il 28 febbraio 2012 15:20, Ezio Melotti <ezio.melotti at gmail.com> ha scritto:

On 28/02/2012 14.19, Antoine Pitrou wrote:

Le mardi 28 février 2012 à 22:14 +1000, Nick Coghlan a écrit :

If you're using separate branches, then your Python 2 code isn't being made forward compatible with Python 3. Yes, it avoids making your Python 2 code uglier, but it means maintaining two branches in parallel until you drop Python 2 support. IMO, maintaining two branches shouldn't be much more work than maintaining hacks so that a single codebase works with two different programming languages. +10 For every CPython bug that I fix I first apply the patch on 2.7, then on 3.2 and then on 3.3. Most of the time I don't even need to change anything while applying the patch to 3.2, sometimes I have to do some trivial fixes.  This is also true for another personal 12kloc project* where I'm using the two-branches approach. For me, the costs of having two branches are:  1) a one-time conversion when the Python3-compatible branch is created (can be done easily with 2to3);  2) merging the fix I apply to the Python2 branch (and with modern DVCS this is not really an issue). With the shared code base approach, the costs are:  1) a one-time conversion to "fix" the code base and make it run on both 2.x and 3.x;  2) keep using and having to deal with hacks in order to keep it running. With the first approach, you also have two clean and separate code bases, with no hacks; when you stop using Python 2, you end up with a clean Python 3 branch. The one-time conversion also seems easier in the first case. (Note: there are also other costs -- e.g. releasing -- that I haven't considered because they don't affect me personally, but I'm not sure they are big enough to make the two-branches approach worse.)

They are. With that kind of approach you're basically forced to include the python version number as part of the tarball name (e.g. foo-0.3.1-py2.tar.gz and foo-0.3.1-py3.tar.gz). Just to name one, that means "foo" can't be installed via pip/easy_install.

Regards,

--- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ http://code.google.com/p/pysendfile/

More information about the Python-Dev mailing list