[Python-Dev] Slow down...

[Brett Cannon]

On Tue, 8 May 2018 at 08:26 Craig Rodrigues <rodrigc at crodrigues.org> wrote:

> On Mon, May 7, 2018 at 2:24 PM Barry Warsaw <barry at python.org> wrote:
>
>> On May 7, 2018, at 11:49, Craig Rodrigues <rodrigc at 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. :)


>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180508/fc616278/attachment.html>