The real problem with Python 3 - no business case for conversion

[Ben Finney]

geremy condra <debatem1 at gmail.com> writes:

> On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel <007brendan at gmail.com> wrote:
> > Python 3.x will continue to change.  The incompatibilities between
> > 3.x and 2.x will only become more numerous.  If your goal is to
> > support 2.x, and 3.x, you'd be best supporting them separately.
>
> I maintain two projects that have to work from 2.5 to 3.1. On one of
> them (~5kloc) we took the separate support route, and on the other
> (~30kloc) I decided to keep a single codebase. IME the maintenance
> burden on the former is substantially higher than the latter.

The point, one more time with feeling, is that the incompatibilities
between 2.x and 3.x will *increase* over time.

If you now have a code base that is relatively easy to maintain for both
Python 2.x and 3.x, that is a result of much back-porting efforts and of
a new-feature moratorium that is currently in effect. Enjoy that
situation as you may, because it is guaranteed not to last.

Indeed, the feature moratorium is designed in part to help slow-moving
codebases migrate to Python 3.x before Python resumes its normal pace of
change again. If you're choosing to use that time to further entrench
codebases for Python 2.x, I think that's a short-sighted choice.

Python 2.7 is the last 2.x, no further 3.x features will be back-ported.
New 3.x features will begin to appear after the moratorium ends. The
combination of those two means that *the single-codebase burden will
only increase over time* as Python 3.x diverges further from what Python
2.x can support.

-- 
 \              “Programs must be written for people to read, and only |
  `\        incidentally for machines to execute.” —Abelson & Sussman, |
_o__)              _Structure and Interpretation of Computer Programs_ |
Ben Finney