[Python-ideas] Making the stdlib consistent again

[Paul Moore]

On 1 August 2016 at 11:05, Eugene Pakhomov <p1himik at gmail.com> wrote:
> Or "you have to keep the old API around" - what is the exact motivation
> behind it? If it's "so the code doesn't break", then it's a strange
> motivation, because as I said, code gets [potentially] broken more often
> that it doesn't. Every alteration/addition/deletion is a potential code
> breakage a priory - aliasing+deprecation is in no way more dangerous than,
> let's say, new zipapp module.

The motivation here is that there are many, many people with deployed
code that uses the existing APIs and names. You are suggesting that we
ask those people to modify their working code to use the new names -
certainly you're proposing a deprecation period, but ultimately the
proposal is to just have the new names. What benefit do you offer to
those people to justify that work? "It's more consistent" isn't going
to be compelling. Further, how will you support people such as library
authors who need their code to work with multiple versions of Python?
What timescale are you talking about here? Library authors are still
having to support 2.7 at present, so until 2.7 is completely gone,
*someone* will have to maintain code that uses both old and new names.
So either your deprecation period is very long (with a consequent cost
on the Python core developers, maintaining 2 names) or some library
authors are left having to maintain their own compatibility code.
Neither is attractive, so again, where's a practical, significant
benefit?

What's the benefit to book authors or trainers who find that their
books/course materials are now out of date, and they are under
pressure to produce a new version that's "up to date"?

The Python core developers take their responsibility not to break
their users' code without good reason very seriously. And from long
experience, we know that we need to consider long timescales. That's
not necessarily something we like (if we were writing things from
scratch, we might well make different decisions) but it's part of the
role of maintaining software that millions of people rely on, often
for core aspects of their business.

> I can't say that I surely do not underestimate the efforts required. But
> what if I want to invest my time in it? If let's say I succeed and do
> everything according to the developer's guide and prove on a number of the
> most popular libraries that the changes indeed do not break anything - will
> be patch be considered or just thrown away with a note "we already discussed
> it"?

You've had the answer a few times in this thread. The benefits have to
outweigh the costs. Vague statements about "consistency" are not
enough, you need to show concrete benefits and show how they improve
things *for the people who have to change their code*.

[From another post]
> But the names still will be deprecated and their use hence will be discouraged - there's no confusion at all.

As long as both names are supported (even deprecated and discouraged
names remain supported) the Python core developers will have to pay
the cost - maintain compatibility wrappers, test both names, etc. How
long do you expect the core devs to do that?

Here - consider this. We rename collections.defaultdict to
collections.DefaultDict (for whatever reason). So now
collections.defaultdict must act the same as collections.DefaultDict.
OK, so someone has the following relatively standard mock object type
of pattern in their test suite:

    # Patch defaultdict for some reason
    collections.defaultdict = MyMockClass
    # Now call the code under test
    test_some_external_function()
    # Now check the results
    MyMockClass.showcallpattern()

Now, suppose that the "external function" switches to use the name
collections.DefaultDict. The above code will break, unless the two
names defaultdict and DefaultDict are updated in parallel somehow to
both point to MyMockClass. How do you propose we support that?

And if your answer is that the user is making incorrect use of the
stdlib, then you just broke their code. You have what you feel is a
justification, but who gets to handle the bug report? Who gets to
support a user whose production code needs a rewrite to work with
Python 3.6? Or to support the author of the external_function()
library who has angry users saying the new version broke code that
uses it, even though the library author was following the new
guidelines given in the Python documentation (I assume you'll be
including documentation updates in your proposal)?

Of course these are unlikely scenarios. I'm not trying to claim
otherwise. But they are the sort of things that the core devs have to
concern themselves with, and that's why the benefits need to justify a
change like this.

Paul