Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Terry Reedy <tjreedy@udel.edu>
Subject: Re: the Gravity of Python 2
Date: Wed, 08 Jan 2014 15:45:16 -0500
References: <laf00q$10k$1@ger.gmane.org> <mailman.5098.1389053970.18130.python-list@python.org> <78d91$52cbf8e9$541826b9$29485@cache1.tilbu1.nb.home.nl> <4b702$52cc262e$541826b9$22985@cache80.multikabel.net> <4cbf$52cc2e82$541826b9$11761@cache70.multikabel.net> <mailman.5141.1389114029.18130.python-list@python.org> <686$52cd4640$541826b9$21896@cache1.tilbu1.nb.home.nl> <roy-C787B2.09153508012014@news.panix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
In-Reply-To: <roy-C787B2.09153508012014@news.panix.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.5199.1389213938.18130.python-list@python.org>
Lines: 45
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:63519

On 1/8/2014 9:15 AM, Roy Smith wrote:
> As somebody who is still firmly in the 2.x world, I'm worried about the
> idea of a 2.x fork.  While I have my doubts that 3.x was a good idea,
> the fact is, it's here.  Having the community fractured between the two
> camps is not good.  Let's say I'm somebody who wants to contribute some
> OSS.  I have three basic choices:
>
> 1) I can make it 3.x only.  Now, (nominally) half of the python
> community is unable to realize value from my contribution.
>
> 2) I can make it 2.x only.  Same thing in reverse.
>
> 3) I can make it work on both 2.x and 3.x, which means I'm investing
> more effort than I had to if it were single platform.
>
> Any of those alternatives is worse than ideal.  Forking 2.x to create an
> unofficial 2.8 release would just prolong the situation.  As I've stated
> before, I don't see any urgency in moving to 3.x, and don't imagine
> doing there for another couple of years, but I absolutely can't imagine
> moving to a 2.8 fork.

This question cannot be answered generically.

I think it worth noting that in part this is the same dilemma as 'how 
many versions to support' within each of 2.x and 3.x. Limiting code to 
3.3+ allows use of the new asyncio module (via Pypy for 3.3) and the new 
FSR unicode. Use of asyncio or FSR features* also forces the choice you 
give above as neither can be backported to 2.7.

* IE, support of all of unicode on all Python systems with 
straightforward code, without contortions.

If I were giving away 'stand-alone' application code whose dependencies 
were available on both 2.7 and 3.x+, I would write for 3.x+ on the basis 
that everyone could install 3.x, and that new users are increasingly 
likely to only have 3.x only. I would have little sympathy for 
organizations that prohibit 3.x -- unless they were to pay me to.

For numerical or combinatorial code, adding 'from __future__ import 
division' (which I think one should do anyway for 2.x code) might be the 
only extra work needed for option 3).

-- 
Terry Jan Reedy