geremy condra <debat...@gmail.com> writes: > On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel <007bren...@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 -- http://mail.python.org/mailman/listinfo/python-list