<div dir="ltr">Thank you very much for the links and the new insights, especially regarding actual user experience with new names. A good reason to start gathering actual statistics.<div>You have made a very good point, I will not reason about naming further without a significant amount of data showing that it still may be worth it.</div><div><br></div><div>Regards,</div><div>Eugene</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 1, 2016 at 7:51 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 1 August 2016 at 20:05, Eugene Pakhomov <<a href="mailto:p1himik@gmail.com">p1himik@gmail.com</a>> wrote:<br>
> It was hardly all of the thoughts, or at least with little background<br>
> information.<br>
<br>
</span>The most pertinent piece of background information is<br>
<a href="http://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html" rel="noreferrer" target="_blank">http://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html</a><br>
<br>
The number of changes we *could* make to Python as a language is<br>
theoretically unbounded. "Can you get current core developers<br>
sufficiently enthusiastic about your idea to encourage you to see it<br>
through to implementation?" is thus one of the main defenses the<br>
language has against churn for churn's sake (it's definitely not the<br>
only one, but it's still a hurdle that a lot of proposals fail to<br>
clear).<br>
<span class=""><br>
> E.g. "multiprocessing and threading" - I can't find any information on it.<br>
> Was it done in one go or gradually by introducing new aliases and<br>
> deprecating old names, at it has been suggested by you (although it was 7<br>
> years ago)?<br>
<br>
</span>All at once, and the old names haven't been removed, and will likely<br>
remain supported indefinitely (there's nothing technically wrong with<br>
them, they just predate the introduction of the descriptor protocol<br>
and Python's adoption of snake_case as the preferred convention for<br>
method and attribute names, and instead use the older Java-style API<br>
with camelCase names and explicit getter and setter methods).<br>
<br>
The implementation issue is <a href="http://bugs.python.org/issue3042" rel="noreferrer" target="_blank">http://bugs.python.org/issue3042</a> but<br>
you'll need to click through to the actual applied patches to see the<br>
magnitude of the diffs (the patches Benjamin posted to the tracker<br>
were only partial ones to discuss the general approach).<br>
<br>
For a decent list of other renames that have largely been judged to<br>
have created more annoyance for existing users than was justified by<br>
any related increase in naming consistency, the six.moves<br>
compatibility module documentation includes a concise list of many of<br>
the renames that took place in the migration to Python 3:<br>
<a href="https://pythonhosted.org/six/#module-six.moves" rel="noreferrer" target="_blank">https://pythonhosted.org/six/#module-six.moves</a><br>
<br>
I've yet to hear a professional educator proclaim their delight at<br>
those renaming efforts, but I *have* received a concrete suggestion<br>
for improving the process next time we decide to start renaming things<br>
to improve "consistency": don't do it unless we have actual user<br>
experience testing results in hand to show that the new names are<br>
genuinely less confusing and easier to learn than the old ones.<br>
<span class=""><br>
> The suggestion about aliases+deprecation has been made for other modules,<br>
> but sadly it ended up with you saying "let's do it this way" - with nothing<br>
> following.<br>
<br>
</span>That's the second great filter for language change proposals: is there<br>
at least one person (whether a current core developer or not) with the<br>
necessary time, energy and interest needed to implement the proposed<br>
change and present it for review?<br>
<span class=""><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.<br>
<br>
</span>Aside from adding new methods to existing classes (which may collide<br>
with added methods in third party subclasses) and the text mock<br>
example Paul cited, additions to existing modules almost never break<br>
things. By contrast, removals almost *always* break things and hence<br>
are generally only done these days when the old ways of doing things<br>
are actively harmful (e.g. the way the misdesigned contextlib.nested<br>
API encouraged resource leaks in end-user applications, or the blurred<br>
distinction between text and binary data in Python 2 encouraged<br>
mishandling of text data).<br>
<span class=""><br>
> 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>
</span>If it's a programmatic deprecation (rather than merely a documented<br>
one), then deprecation absolutely *does* force folks that have a "no<br>
warnings" policy for their test suites to update their code<br>
immediately. It's the main reason we prefer to only deprecate things<br>
when they're actively harmful, rather than just because they're no<br>
longer fashionable.<br>
<br>
While standard library module additions can indeed pose a<br>
compatibility challenge (due to the way module name shadowing works),<br>
the typical worst case scenario there is just needing some explicit<br>
sys.path manipulation to override the stdlib version specifically for<br>
affected applications, and even that only arises if somebody has an<br>
existing internal package name that collides with the new stdlib one<br>
(we try to avoid colliding with names on PyPI).<br>
<span class=""><br>
> I in no way state that the changes should include a complete overhaul or be<br>
> done in one go. But maybe we can at least start gradually introducing some<br>
> naming changes to the oldest, most used and least changed (w.r.t. API)<br>
> modules?<br>
<br>
</span>That's a different proposal from wholesale name changes, as it allows<br>
each change to be discussed on its individual merits rather than<br>
attempting to establish a blanket change in development policy.<br>
<span class=""><br>
> The perfect example I think is collections module, but it's only from the<br>
> personal experience - other modules may be better candidates.<br>
<br>
</span>collections has the challenge that the normal PEP 8 guidelines don't<br>
apply to the builtins, so some collections types are named like<br>
builtins (deque, defaultdict), while others follow normal class naming<br>
conventions (e.g. OrderedDict). There are also type factories like<br>
namedtuple, which again follow the builtin convention of omitting<br>
underscores from typically snake_case names.<br>
<span class=""><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?<br>
<br>
</span>It's not contributor time or even core developer time that's the main<br>
problem in cases like this, it's the flow on effect on books,<br>
tutorials, and other learning resources. When folks feel obliged to<br>
update those, we want them to able to say to themselves "Yes, the new<br>
way of doing things is clearly better for my students and readers than<br>
the old way".<br>
<br>
When we ask other people to spend time on something, the onus is on us<br>
to make sure that at least we believe their time will be well spent in<br>
the long run (even if we're not 100% successful in convincing them of<br>
that in the near term). If even we don't think that's going to be the<br>
case, then the onus is on us to avoid wasting their time in the first<br>
place. We're never going to be 100% successful in that (we're always<br>
going to approve some non-zero number of changes that, with the<br>
benefit of hindsight, turn out to have been more trouble than they<br>
were worth), but it's essential that we keep the overall cost of<br>
change to the entire ecosystem in mind when reviewing proposals,<br>
rather than taking a purely local view of the costs and benefits at<br>
the initial implementation level.<br>
<span class=""><br>
> 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>
</span>It would depend on the specific change you propose, and the rationale<br>
you give for making it. If the only rationale given is "Make <API><br>
more compliant with PEP 8", then it will almost certainly be knocked<br>
back.<br>
<br>
Cheers,<br>
Nick.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</font></span></blockquote></div><br></div>