The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")

[geremy condra]

On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel <007brendan at gmail.com> wrote:
> On Jul 7, 3:00 pm, MRAB <pyt... at 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