[Python-Dev] 2.7 is here until 2020, please don't call it a waste.

Sat May 30 00:44:41 CEST 2015

On 30 May 2015 07:14, "Gregory P. Smith" <greg at krypto.org> wrote:
>
>
> On Fri, May 29, 2015 at 12:24 AM Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>>
>> On 29 May 2015 11:01 am, "Victor Stinner" <victor.stinner at gmail.com>
wrote:
>> >
>> > Why not continue to enhance Python 3 instead of wasting our time with
>> > Python 2? We have limited resources in term of developers to maintain
>> > Python.
>> >
>> > (I'm not talking about fixing *bugs* in Python 2 which is fine with
me.)
>>
>> I'm actually OK with volunteers deciding that even fixing bugs in 2.7
isn't inherently rewarding enough for them to be willing to do it for free
on their own time.
>
>
> That is 100% okay.
>
> What is not okay is for python-dev representatives to respond to users
(in any list/forum/channel) reporting bugs in 2.7 or asking if a fix in 3
can be backported to 2.7 with things akin to "just use Python 3" or "sorry,
2.7 is critical fixes only. move to python 3 already." This is actively
driving our largest users away.  I bring this up because a user was
bemoaning how useless they feel python core devs are because of this
attitude recently. Leading to feelings of wishing to just abandon CPython
if not Python all together.
>
> I'm sure I have even made some of those responses myself (sorry!). My
point here is: know it. recognize it. don't do it anymore. It harms the
community.
>
> A correct and accurate response to desires to make non-api-breaking
changes in 2.7 is "Patches that do not change any APIs for 2.7 are welcome
in the issue tracker." possibly including "I don't have the bandwidth to
review 2.7 changes, find someone on python-dev to review and champion this
for you if you need it."  Finding someone may not always be easy. But at
least is still the "patches welcome" attitude and suggests that the work
can be done if someone is willing to do it. Lets make a concerted effort to
not be hostile and against it by default.

Better answer (and yes, I'm biased): "Have you asked your Python support
vendor to push for this change on your behalf?"

If well-funded entities expect open source software to just magically be
maintained without them paying someone to maintain it (whether that's their
own developers or a redistributor), then their long term risk management
processes are fundamentally broken and they need to reconsider their
approach.

> Ex: Is someone with a python application that is a million of lines
supposed to have everyone involved in that drop the productive work they
are doing and spend that porting their existing application to python 3
because we have so far failed to provide the tools to make that migration
easy?  No.  Empathize with our community.  Feel their pain.  (and everyone
who is working on tools to aid the transition: keep doing that! Our users
are gonna need it unless we don't want them as users anymore.)

Are they paying someone for Python support (or at least sponsoring the
Python Software Foundation)? If they're paying for support, are they
working with that vendor to figure out how they're going to manage the
transition to Python 3? If they're not paying for support, are they
actively participating in the community such that I know their developers
at a personal level and care about them as friends & colleagues?

If the answer to all three of those questions is "No", then no, I don't
have any sympathy for them. In the first case, my response is "Stop being a
freeloader on the generosity of the Python community and pay someone", in
the second case it's "Go make use of that commercial support you're paying
for (and stop breaking our core development funding signals by bypassing
it)", while in the third it's "What have you done for *me* lately that
should make me care about your inability to appropriately manage business
risk?".

> We committed to supporting 2.7 until 2020 in 2014 per
https://hg.python.org/peps/rev/76d43e52d978.  That means backports of
important bug or performance fixes should at least be allowed on the table,
even if hairy, even if you won't work on them yourselves on a volunteer
basis. This is the first long term support release of Python ever. This is
what LTS means.  LTS could also stand for Learn To Support...

It also stands for commercial redistributors and the infrastructure teams
at large institutions actually doing what we're paid for, rather than
expecting other volunteers to pick up our slack.

The only thing we can legitimately ask volunteers to do is to not *object*
while we do this, and for them to redirect well-funded end users to paid
support options and other means of contributing back to the Python
community, rather than haranguing them to "just upgrade already".

Regards,
Nick.

>
> -gps
>>
>> Stepping up to extrinsically reward activities that are beneficial for
customers but aren't intrinsically interesting enough for people to be
willing to do for free is one of the key reasons commercial open source
redistributors get paid.
>>
>> That more explicitly commercial presence is a dynamic we haven't
historically had to deal with in core development, so there are going to be
some growing pains as we find an arrangement that everyone is comfortable
with (or is at least willing to tolerate, but I'm optimistic we can do
better than that).
>>
>> Cheers,
>> Nick.
>>
>> >
>> > --
>> >
>> > By the way, I just wrote sixer, a new tool to generate patches to port
>> > OpenStack to Python 3 :-)
>> > https://pypi.python.org/pypi/sixer
>> >
>> > It's based on regex, so it's less reliable than 2to3, 2to6 or
>> > modernize, but it's just enough for my specific use case. On
>> > OpenStack, it's not possible to send one giant patch "hello, this is
>> > python 3". Code is modified by small and incremental changes.
>> >
>> > Come on in the Python 3 world and... always look on the bright side of
>> > life ( https://www.youtube.com/watch?v=VOAtCOsNuVM )!
>> >
>> > Victor
>> > _______________________________________________
>> > 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
>>
>> _______________________________________________
>> 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/greg%40krypto.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150530/6e46537a/attachment-0001.html>