when will python 2.5 take in mainstream?

[Jean-Paul Calderone]

On Mon, 05 Feb 2007 17:07:15 +0100, Laurent Pointal <laurent.pointal at limsi.fr> wrote:
>Jean-Paul Calderone a écrit :
>> On Mon, 05 Feb 2007 10:19:26 +0100, Laurent Pointal
>> <laurent.pointal at limsi.fr> wrote:
>>> tleeuwenburg at gmail.com a écrit :
>>>> When they have to ...
>>>>
>>>> One of the big things about Python is that its penetration slows it
>>>> down. There's more legacy code and interdependant systems around now
>>>> that Python is more successful and more mature.
>>>>
>>>> Here's a thought -- perhaps it would be worth having some good ways to
>>>> interact with Python from Python. Suppose you have some 2.4 code
>>>> someplace, interacting with your mysqldb or whatever, and you don't
>>>> want to rewrite it. So long as you have some kind of object broker,
>>>> you could (plausibly) leave your 2.4 apps running with the old
>>>> interpreter, but wrap them for Python 2.5 and use that in your new
>>>> development.
>>>
>>> KISS please.
>>>
>>
>> Requiring change is simpler than not requiring change?
>> Okay, perhaps
>> you could make a case, but it's far from obvious this is always true.
>>
>
>IMHO trying to have a binary compatibility with older compiled modules
>by maintaining an ad-hoc layer to switch between 2.4/2.5 engines make
>Python code more complex. And more complex code have generally more
>bugs. This is the reason for my KISS hope about Python.
>
>Its simple to require changes, not so sure that doing these
>modifications keep things simple. Maybe an internal Python hacker can
>give us his advice on such a modification (ie. staying compatible with
>legacy modules compiled for previous versions).
>

It's very easy to maintain compatibility in the C API.  I'm much more
interested in compatibility at the Python layer, which is changed
incompatibly much, much more frequently than is the C layer.

Anyway, you didn't address my point.  Maintaining compatibility in
Python itself might be more complex than not maintaining complexity.
But _not_ maintaining compatibility just pushes the complexity into
every program and library written with Python.  Which one of these
things do you think results in more developer time being spent? (Hint:
it's the 2nd one.)

Don't mistake this for advocacy that Python never break any compatibility.
Whether or not I think that is the case is unrelated to whether or not
it is useful to understand and admit all of the costs associated with
breaking compatibility.

Jean-Paul