[Python-Dev] death to 2.7; long live 2.7

Nick Coghlan ncoghlan at gmail.com
Thu Apr 10 05:38:17 CEST 2014


On 9 Apr 2014 22:11, "Guido van Rossum" <guido at python.org> wrote:
>
> On Wed, Apr 9, 2014 at 9:39 PM, Benjamin Peterson <benjamin at python.org>
wrote:
>>
>>
>>
>> On Wed, Apr 9, 2014, at 18:31, Guido van Rossum wrote:
>> > I think this is pretty much what Nick Coghlan implied at the summit.
>>
>> He implied that it's currently the plan or that it should be the plan?
>
>
> As you might understand, we couldn't actually *decide* anything at the
summit, but that should be the plan.

Yeah, I think it's on us and other commercial redistributors to figure out
how to best meet our long term support commitments to our users, and I
personally think that meeting those obligations cost effectively will
involve more direct *upstream* involvement in the long term maintenance of
the Python 2.7 series. That's largely boring-but-necessary drudgery, and
that's the kind of development gap that open source vendors excel at
addressing.

Still a lot of legwork to get from "I think this is a good way to handle
the problem" to actually making it happen, but as the saying goes: if you
don't ask, you don't get :)

I believe a defined end date for volunteer provided backports actually
helps make that case (and the advance warning also provides lead time to
hopefully do something about it).

> Nick implied that Red Hat has a relevant announcement it will make in two
weeks, but wouldn't say more.

Kinda wishing I hadn't said anything at all, now - I suspect the temporary
vagueness means I'm now building up anticipation that will inevitably lead
to disappointment with any actual announcement :(

I *can* at least say that we're (all too well) aware of the issues
associated with consuming newer dynamic language runtimes on our stable
platforms, and we're definitely interested in making it easier for users to
deploy and use newer versions of these without harming the consistency and
integrity of their system. Assuming we can find an approach (or approaches)
that work well for a wide variety of use cases, this should allow us to
help reduce the pressure on the developers of upstream Python libraries and
frameworks to keep supporting the versions installed system wide in our
long term maintenance releases (OpenShift and software collections are a
couple of existing efforts that handle some aspects of this issue, but I
certainly don't consider the general problem solved at this point).

Regards,
Nick.

>
> --
> --Guido van Rossum (python.org/~guido)
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140409/241f94a0/attachment.html>


More information about the Python-Dev mailing list