<div dir="ltr"><div>On 1 August 2016 at 13:45, Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>> On 1 August 2016 at 11:05, Eugene Pakhomov <<a href="mailto:p1himik@gmail.com">p1himik@gmail.com</a>> wrote:<br>>> Or "you have to keep the old API around" - what is the exact motivation<br>>> behind it? If it's "so the code doesn't break", then it's a strange<br>>> motivation, because as I said, code gets [potentially] broken more often<br>>> that it doesn't. Every alteration/addition/deletion is a potential code<br>>> breakage a priory - aliasing+deprecation is in no way more dangerous than,<br>>> let's say, new zipapp module.<br><br>> What timescale are you talking about here? Library authors are still<br>> having to support 2.7 at present, so until 2.7 is completely gone,<br>> *someone* will have to maintain code that uses both old and new names.<br>> So either your deprecation period is very long (with a consequent cost<br>> on the Python core developers, maintaining 2 names) or some library<br>> authors are left having to maintain their own compatibility code.<br>> Neither is attractive, so again, where's a practical, significant<br>> benefit?<br><br>Double names maintenance is not really an issue in my opinion. Earlier this<br>thread there was a valid point for aliasing, which from my perspective needs<br>little maintenance if any, with no cost towards performance.<br><br>> What's the benefit to book authors or trainers who find that their<br>> books/course materials are now out of date, and they are under<br>> pressure to produce a new version that's "up to date"?<br><br>New books get written all the time, but 'getting it up-to-date' is not needed<br>when aliases are put in place, with deprecation warnings for e.g. when<br>support for 2.7 and <last not-renamed Python version> both are discontinued.<br>That gives both authors and users enough time to adapt their relative works.<br><br>> The Python core developers take their responsibility not to break<br>> their users' code without good reason very seriously. And from long<br>> experience, we know that we need to consider long timescales. That's<br>> not necessarily something we like (if we were writing things from<br>> scratch, we might well make different decisions) but it's part of the<br>> role of maintaining software that millions of people rely on, often<br>> for core aspects of their business.<br><br>Especially on the long run people who get in touch with python will again<br>and again find out that the names in python are not consistent. If this<br>can be solved, why not do so?<br><br>>> I can't say that I surely do not underestimate the efforts required. But<br>>> what if I want to invest my time in it? If let's say I succeed and do<br>>> everything according to the developer's guide and prove on a number of the<br>>> most popular libraries that the changes indeed do not break anything - will<br>>> be patch be considered or just thrown away with a note "we already discussed<br>>> it"?<br><br>> You've had the answer a few times in this thread. The benefits have to<br>> outweigh the costs. Vague statements about "consistency" are not<br>> enough, you need to show concrete benefits and show how they improve<br>> things *for the people who have to change their code*.<br><br>> [From another post]<br>>> But the names still will be deprecated and their use hence will be<br>>> discouraged - there's no confusion at all.<br><br>> As long as both names are supported (even deprecated and discouraged<br>> names remain supported) the Python core developers will have to pay<br>> the cost - maintain compatibility wrappers, test both names, etc. How<br>> long do you expect the core devs to do that?<br><br>Compatebility wrappers only have to be of one type: make the content of<br>package variable 'a' be the same as package variable 'A'. This can be done by<br>allowing the containing structure of variables be pointed to by multiple<br>variable names, which would allow for library maintainers to just insert <br></div>the new name, and point it to the correct variable container.<br><div><div><div><br>>     # Patch defaultdict for some reason<br>>     collections.defaultdict = MyMockClass<br>>     # Now call the code under test<br>>     test_some_external_function()<br>>     # Now check the results<br>>     MyMockClass.showcallpattern()<br><br>> Now, suppose that the "external function" switches to use the name<br>> collections.DefaultDict. The above code will break, unless the two<br>> names defaultdict and DefaultDict are updated in parallel somehow to<br>> both point to MyMockClass. How do you propose we support that?<br><br>This would be fixed with the 'aliasing variable names'-solution.<br><br>> And if your answer is that the user is making incorrect use of the<br>> stdlib, then you just broke their code. You have what you feel is a<br>> justification, but who gets to handle the bug report? Who gets to<br>> support a user whose production code needs a rewrite to work with<br>> Python 3.6? Or to support the author of the external_function()<br>> library who has angry users saying the new version broke code that<br>> uses it, even though the library author was following the new<br>> guidelines given in the Python documentation (I assume you'll be<br>> including documentation updates in your proposal)?<br><br>Changing supported Python versions will always change behaviour of <br>someone's code. There's a nice statement about that on XKCD: <br>(<a href="https://xkcd.com/1172/">https://xkcd.com/1172/</a>). Although I know this is also an extreme example, <br>this does not mean that it is not correct: If there is a point in which we <br>can make Python/stdlib easier to work with, then maybe we should do so to <br>make things more consistent and easier to learn.<br><br>-Matthias</div></div></div></div>