[Python-Dev] PEP 414 - Unicode Literals for Python 3

[Giampaolo Rodolà]

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/