the Gravity of Python 2

[Terry Reedy]

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