> On May 8, 2018, at 11:48 AM, Brett Cannon <br...@python.org> wrote: > > > >> On Tue, 8 May 2018 at 08:26 Craig Rodrigues <rodr...@crodrigues.org> wrote: >>> On Mon, May 7, 2018 at 2:24 PM Barry Warsaw <ba...@python.org> wrote: >>> On May 7, 2018, at 11:49, Craig Rodrigues <rodr...@crodrigues.org> wrote: >>> > >>> > Would it be reasonable to request a 10 year moratorium on making changes >>> > to the core Python language, >>> > and for the next 10 years only focus on things that do not require core >>> > language changes, >>> > such as improving/bugfixing existing libraries, writing new libraries, >>> > improving tooling, improving infrastructure (PyPI), >>> > improving performance, etc., etc.? >>> >>> IMHO, no. >>> >>> 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. >>> >>> 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. >>> >>> 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. >>> >> >> 10 years is a long time for many types of applications, such as web server >> and desktop applications >> where regular and somewhat frequent upgrades can happen. >> However, I have worked on embedding Python in networking and storage devices. >> It is true that many of these types of devices can also have their software >> upgraded, >> but often the frequency of such upgrades is much slower than for >> conventional web server and desktop applications. >> Upgrades of these devices usually spans user-space and kernel/device >> drivers, so >> upgrades are usually done more cautiously and less frequently. >> >> For Python 2.x, the ship has sailed. However, 10 years from now, if the >> Python language >> is pretty much the same as Python 3.7 today, that would be nice. > > Then feel free to stay on Python 3.7. We have versioned releases so people > can choose to do that. :)
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. Eric > >> >> I'm not stuck on the number "10 years", but I am just throwing it out there >> as a draft proposal. >> So even 5-8 year moratorium would be nice to strive for. > > 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? > > 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. > >> >> >> Outside of the embedded space, I will give another example where folks in >> industry are behind. >> I don't want to pick on a particular vendor, but from April 24-26, I >> attended training sessions at RedisConf18 in San Francisco. >> During the training sessions, multiple sample Python code examples were >> given for accessing the Redis database. >> The instructor thought that the code examples worked in Python 3, but in >> fact, they only worked in Python 2 mostly due to >> bytes/unicode issues. During the class, I fixed the examples for Python 3 >> and submitted the patches to the instructor, >> who gratefully accepted my patches. However, there are going to be many, >> many users of Redis out there who >> maybe will not upgrade their Python code for newer versions of Python for >> many years. > > Why is Redis specifically going to be behind specifically? Are they embedding > the interpreter? > >> >> Besides Redis users, I am seeing all sorts of communities and companies >> which are behind in terms of having working >> code and documentation that works on latest Python 3. It is going to take >> YEARS for all these communities and companies >> to catch up (if ever). > > 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. > >> >> I understand that Python as a language must evolve over time to succeed and >> thrive. But I would request that >> at least for the next 5-10 years, a moratorium on language changes be >> considered, to allow the world to catch >> up in terms of code, documentation, and mind/understanding. > > 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). > >> >> >> Looking back at how the Python 2.7 EOL was extended by 5 years, I would >> remind the core Python developers >> that it is very easy to underestimate how slow the world is to change their >> code, documentation, training, >> and understanding to adapt to new Python versions. Going slow or imposing >> a moratorium wouldn't be such a bad thing. > > 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. ;) > > 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. > _______________________________________________ > 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/eric%2Ba-python-dev%40trueblade.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/archive%40mail-archive.com
