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
--
https://mail.python.org/mailman/listinfo/python-list
