geremy condra wrote:
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?
In my work on the regex module I use a single codebase and generate the
sources for Python 2.5-2.7 and for Python 3.1 from it. It works easily
enough for me.
--
http://mail.python.org/mailman/listinfo/python-list
