<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><div>On May 8, 2018, at 11:48 AM, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, 8 May 2018 at 08:26 Craig Rodrigues <<a href="mailto:rodrigc@crodrigues.org">rodrigc@crodrigues.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, May 7, 2018 at 2:24 PM Barry Warsaw <<a href="mailto:barry@python.org" target="_blank">barry@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On May 7, 2018, at 11:49, Craig Rodrigues <<a href="mailto:rodrigc@crodrigues.org" target="_blank">rodrigc@crodrigues.org</a>> wrote:<br>
> <br>
> Would it be reasonable to request a 10 year moratorium on making changes to the core Python language,<br>
> and for the next 10 years only focus on things that do not require core language changes,<br>
> such as improving/bugfixing existing libraries, writing new libraries, improving tooling, improving infrastructure (PyPI),<br>
> improving performance, etc., etc.?<br>
<br>
IMHO, no.<br>
<br>
I don’t believe that the way for Python to remain relevant and useful for the next 10 years is to cease all language evolution. Who knows what the computing landscape will look like in 5 years, let alone 10? Something as arbitrary as a 10 year moratorium is (again, IMHO) a death sentence for the language.<br>
<br>
But I do think it makes sense to think about how Python-the-language and CPython-the-reference implementation can better balance the desire to evolve vs the need to concentrate on improving what we’ve got. With that in mind, it does make sense to occasionally use a moratorium release to focus on tech debt, cleaning up the stdlib, improve performance, etc.<br>
<br>
CPython’s 18 month release cycle has served us well for a long time, but I do think it’s time to discuss whether it will still be appropriate moving forward. I’m not saying it is or isn’t, but with the release of 3.7, I think it’s a great time to explore our options.<br><br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>10 years is a long time for many types of applications, such as web server and desktop applications</div><div>where regular and somewhat frequent upgrades can happen.</div><div>However, I have worked on embedding Python in networking and storage devices.</div><div>It is true that many of these types of devices can also have their software upgraded,</div><div>but often the frequency of such upgrades is much slower than for conventional web server and desktop applications.</div><div>Upgrades of these devices usually spans user-space and kernel/device drivers, so</div><div>upgrades are usually done more cautiously and less frequently.</div><div><br></div><div>For Python 2.x, the ship has sailed. However, 10 years from now, if the Python language</div><div>is pretty much the same as Python 3.7 today, that would be nice.</div></div></div></blockquote><div><br></div><div>Then feel free to stay on Python 3.7. We have versioned releases so people can choose to do that. :)<br></div></div></div></div></blockquote><div><br></div>Also, you can pay people to support old versions, and sometimes even backport features you need. So I think this use case is already covered. You just can’t expect to hold up language development because you want to have a stable supported version. <div><br></div><div>Eric </div><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>I'm not stuck on the number "10 years", but I am just throwing it out there as a draft proposal.</div><div>So even 5-8 year moratorium would be nice to strive for.</div></div></div></blockquote><div><br></div><div>Timespans of that length are still too long to freeze the language. Look at it this way: node.js 0.10.0 was released 5 years ago and now it's a thing. If we had not moved forward and added async/await in Python 3.5 -- which was only 3 years ago -- but instead froze ourselves for 5 years would we be considered relevant in the networking world like we are, or viewed as somewhat as a dinosaur?<br><br></div><div>I realize the embedded world moves at a different pace (as well as other groups of developers), but that doesn't mean we have to move at the speed of our slowest adopters to punish those willing and wanting newer features.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div><br></div><div>Outside of the embedded space, I will give another example where folks in industry are behind.</div><div>I don't want to pick on a particular vendor, but from April 24-26, I attended training sessions at RedisConf18 in San Francisco.</div><div>During the training sessions, multiple sample Python code examples were given for accessing the Redis database.</div><div>The instructor thought that the code examples worked in Python 3, but in fact, they only worked in Python 2 mostly due to</div><div>bytes/unicode issues. During the class, I fixed the examples for Python 3 and submitted the patches to the instructor,</div><div>who gratefully accepted my patches. However, there are going to be many, many users of Redis out there who</div><div>maybe will not upgrade their Python code for newer versions of Python for many years.</div></div></div></blockquote><div><br></div><div>Why is Redis specifically going to be behind specifically? Are they embedding the interpreter?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Besides Redis users, I am seeing all sorts of communities and companies which are behind in terms of having working</div><div>code and documentation that works on latest Python 3. It is going to take YEARS for all these communities and companies</div><div>to catch up (if ever).</div></div></div></blockquote><div><br></div><div>And that's fine. If they want to continue to maintain Python 2 and stay on it, or simply stick with our final release and never worry about potential security issues, that's their prerogative. But once again, we shouldn't have to hold up the entire language for the slowest adopters.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><div>I understand that Python as a language must evolve over time to succeed and thrive. But I would request that</div><div>at least for the next 5-10 years, a moratorium on language changes be considered, to allow the world to catch</div><div>up in terms of code, documentation, and mind/understanding.</div></div></div></blockquote><div><br></div><div>5 years is 3-4 releases, 10 years is 6-7. That's basically saying we should still be like 3.3/3.2 or 2.7, both of which I don't think the majority of people want (I know I am a happier programmer in 3.6 than I am in any of those versions).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div><br></div><div>Looking back at how the Python 2.7 EOL was extended by 5 years, I would remind the core Python developers</div><div>that it is very easy to underestimate how slow the world is to change their code, documentation, training,</div><div>and understanding to adapt to new Python versions. Going slow or imposing a moratorium wouldn't be such a bad thing.</div></div></div></blockquote><div><br></div><div>I think a better way to phrase this is, "should we not change the language because there are still people on Python 3.3? We've already stated many times that there won't be a major language upheaval like 2/3 ever again, so we are only talking about changes on the order of e.g. 3.5/3.6. And for me, I like what we have added. I am certainly not about to ask anyone to give up f-strings and deal with those pitchforks. ;)<br><br></div><div>And if people don't upgrade then people don't upgrade. We have all the old versions of libraries on PyPI, so people can continue to use the libraries that they were depending on when they choose to not move forward with Python releases and continue to function.<br></div></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Python-Dev mailing list</span><br><span><a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a></span><br><span><a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a></span><br><span>Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com">https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com</a></span><br></div></blockquote></div></body></html>