[Python-ideas] Making the stdlib consistent again

[Nick Coghlan]

On 26 July 2016 at 05:23, Paul Moore <p.f.moore at gmail.com> wrote:
> So overall, I think practicality beats purity here, and such a change
> is not worth the effort.

We did go through the effort for the threading module, as we had the
problem there that multiprocessing was PEP-8 compliant (with aliases
for threading compatibility), but threading only had the old pre-PEP-8
names.

A couple of the conclusions that came out of that were:

- it was probably worth it in threading's case due to the improved
alignment with multiprocessing
- it isn't worth the disruption in the general case

The "isn't worth it" mainly comes from the fact that these APIs
generally *were* compliant with the coding guidelines that existed at
the time they were first written, it's just that the guidelines and
community expectations have changed since then, so they represent
things like "good Python design style circa 1999" (e.g. unittest,
logging) rather than "good Python style for today". So if you say
"let's update them to 2016 conventions" today, by 2026 you'll just
have the same problem again.

It ends up being one of those cases where "invest development time now
to reduce cognitive burden later" doesn't actually work in practice,
as you have to keep the old API around anyway if you don't want to
break working code, and that means future learners now have two APIs
to learn instead of one (and if you refresh the API to the design du
jour ever decade or so, that number keeps going up).

Instead, for these older parts of the standard library, it's useful to
view them as "interoperability plumbing" (e.g. logging for event
stream reporting and management, unittest for test case reporting and
management), and look for more modern version independent 3rd party
facades if you find the mix of API design eras in the standard library
annoying (e.g. pytest as an alternative to raw unittest, structlog
over direct use of the logging module)

Cheers,
Nick.

P.S. I sometimes wonder if you could analyse Python API designs over
time and group them into eras the way people do with building
architectural styles - "This API is a fine example of the stylistic
leanings of Python's Java period, which ran from <year> to <year>. As
the community moved into the subsequent Haskell period, composition
came to be favoured over inheritance, leading to the emergence of
alternative APIs like X, Y, and Z, of which, Y ultimately proved to be
most popular" :)

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia