[Python-ideas] Making the stdlib consistent again

[Matthias welp]

On 1 August 2016 at 13:45, Paul Moore <p.f.moore at gmail.com> wrote:
> 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.

> 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?

Double names maintenance is not really an issue in my opinion. Earlier this
thread there was a valid point for aliasing, which from my perspective needs
little maintenance if any, with no cost towards performance.

> 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"?

New books get written all the time, but 'getting it up-to-date' is not
needed
when aliases are put in place, with deprecation warnings for e.g. when
support for 2.7 and <last not-renamed Python version> both are discontinued.
That gives both authors and users enough time to adapt their relative works.

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

Especially on the long run people who get in touch with python will again
and again find out that the names in python are not consistent. If this
can be solved, why not do so?

>> 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?

Compatebility wrappers only have to be of one type: make the content of
package variable 'a' be the same as package variable 'A'. This can be done
by
allowing the containing structure of variables be pointed to by multiple
variable names, which would allow for library maintainers to just insert
the new name, and point it to the correct variable container.

>     # 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?

This would be fixed with the 'aliasing variable names'-solution.

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

Changing supported Python versions will always change behaviour of
someone's code. There's a nice statement about that on XKCD:
(https://xkcd.com/1172/). Although I know this is also an extreme example,
this does not mean that it is not correct: If there is a point in which we
can make Python/stdlib easier to work with, then maybe we should do so to
make things more consistent and easier to learn.

-Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160801/0b9d3431/attachment-0001.html>