On 26 July 2016 at 16:53, Greg Ewing <greg.ewing@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@gmail.com | Brisbane, Australia