[Python-Dev] Slow down...

[Craig Rodrigues]

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.

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.


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.

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).

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.


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.

--
Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180508/c120f7a2/attachment.html>