Il 28 febbraio 2012 15:20, Ezio Melotti <ezio.melo...@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/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
