On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel <007bren...@gmail.com> wrote: > On Jul 7, 3:00 pm, MRAB <pyt...@mrabarnett.plus.com> wrote: >> Brendan Abel wrote: >> >>>> One thing that would be very useful is how to maintain something that >> >>>> works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up >> >>>> versions below 2.6 is out of the question for most projects with a >> >>>> significant userbase IMHO. As such, the idea of running the python 3 >> >>>> warnings is not so useful IMHO - unless it could be made to work >> >>>> better for python 2.x < 2.6, but I am not sure the idea even makes >> >>>> sense. >> >> > The entire fact that 3.x was *designed* to be incompatible should tell >> > you that supporting 2.x and 3.x with a single code base is a bad idea, >> > except for the very smallest of projects. This is the point where a >> > project should fork and provide two different versions. >> >> I wouldn't say that 3.x was designed to be incompatible. It was designed >> to tidy the language, and the incompatibilities are an unfortunate >> result. > > You're missing the point, and arguing semantics. It's a good thing I > didn't misspell anything. > > 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. Is the difference in difficulty perhaps domain-related, or a result of a certain style of coding? Could you give us some more details about what you were working on that caused you to conclude this? Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
