On 30 May 2015 07:14, "Gregory P. Smith" <g...@krypto.org> wrote: > > > On Fri, May 29, 2015 at 12:24 AM Nick Coghlan <ncogh...@gmail.com> wrote: >> >> >> On 29 May 2015 11:01 am, "Victor Stinner" <victor.stin...@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@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@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
