[Python-ideas] Making the stdlib consistent again

[Nick Coghlan]

On 26 July 2016 at 16:53, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Nick Coghlan wrote:
>> So if you say
>> "let's update them to 2016 conventions" today, by 2026 you'll just
>> have the same problem again.
>
> You're assuming that the conventions will change just as
> much in the next 10 years as they did in the last 10. I
> don't think that's likely -- I would hope we're converging
> on a set of conventions that's good enough to endure.

Conventions can really only remain stable if their environment doesn't
change, and the software development world isn't that much more stable
now than it was 20 years ago.

>> and look for more modern version independent 3rd party
>> facades if you find the mix of API design eras in the standard library
>> annoying
>
> It would be sad if Python's motto became "Batteries
> included (as long as you're happy with Leclanche cells;
> if you want anything more modern you'll have to look
> elsewhere)".

New libraries can still make their way into the standard set, but it
makes more sense to do that as *actual new libraries*, rather than
simply PEP-8-ifying old ones.

It's relatively easy to manage the cognitive burden of argparse vs
optparse vs getopt, for example - you know which one people are using
based on what they import, and they have different names so it's easy
to talk about the trade-offs between them and tell people which one is
recommended for new code.

Ditto for asyncio vs asynchat and asyncore.

We even have a section in the docs specifically for modules that are
still around for backwards compatibility, but we don't recommend to
new users: https://docs.python.org/3/library/superseded.html

So evolving the standard library by introducing new ways of doing
things as the community learns better alternatives, and requiring
those new ways to be compliant with PEP 8 at the time they're
standardised *absolutely* makes sense.

The only part I don't think makes sense is modernising the APIs of
existing modules purely for the sake of modernising them - there needs
to be a stronger justification for expending that much effort (as
there was with properly aligning the threading and multiprocessing
APIs).

Cheers,
Nick.

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