<div dir="ltr">Hi Paul,<div><br></div><div>Thanks for typing that all out and taking the time to respond to my emails. I think as you say, it might be good to put this somewhere obvious.</div><div><br></div><div>I did find <a href="https://docs.python.org/devguide/langchanges.html">https://docs.python.org/devguide/langchanges.html</a> and <a href="http://www.curiousefficiency.org/posts/2011/02/justifying-python-language-changes.html">http://www.curiousefficiency.org/posts/2011/02/justifying-python-language-changes.html</a> but the things you wrote would be useful to add the former (or be linked from there). It would also be good if there was a counter-point to that blog post of changes (like this one) that are not sufficiently thought through or significant enough to be accepted: it is always good to have examples on both sides.</div><div><br></div><div>In terms of your "it keeps coming up", maybe there should be a general PEP (or something else) that simply outlines a bunch of ideas (and will be kept adding to) that keep cropping up but have been rejected/received unsympathetically many times? Including maybe links to these threads?</div><div><br></div><div>Maybe that is something that could save you (and others subscribed) time and effort?</div><div><br></div><div>H-J</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 February 2017 at 15:02, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23 February 2017 at 14:20, Henk-Jaap Wagenaar<br>
<span class=""><<a href="mailto:wagenaarhenkjaap@gmail.com">wagenaarhenkjaap@gmail.com</a>> wrote:<br>
><br>
> In a straw poll at the company I work at everyone was in favour, though they<br>
> obviously are not in charge of implementing or changing documentation so<br>
> that is easy for them to say, they've got no skin in the game. I don't know<br>
> whether it is common for such an idea to be brought up again and again by<br>
> newcomers/those who don't strolls the archives enough, but if it keeps being<br>
> brought up, and the main argument against is it would take time and effort<br>
> to document and implement for little benefit, if Python sticks around for a<br>
> long enough time, it will end up taking less time simply implement it!<br>
<br>
</span>We really need a FAQ for this, if there isn't one already. You quoted<br>
Nick referring to a post I'd already made on this, and while I'm<br>
afraid I don't have time to find a link for you, I'll try to summarise<br>
again here.<br>
<br>
The bar for syntax changes to Python (and also library changes,<br>
although to a slightly lesser extent) is deliberately very high. This<br>
is not because people don't like proposals, but rather because the<br>
proposers consistently and drastically underestimate the cost of<br>
adding new features to the language.<br>
<br>
Things that need to be factored into the cost of a change:<br>
<br>
1. Written materials, such as books, training courses, blog posts will<br>
be out of date, at best offering obsolete advice, at worst being<br>
outright wrong. Either the authors have extra work to do to change<br>
them, or the readers need to learn the "new truth", probably by making<br>
mistakes that they could have avoided if the material were correct.<br>
2. Core developers need to understand the implementation of the new<br>
feature in order to support it.<br>
3. Unintended consequences and/or problems with the design of the new<br>
feature (= bugs) need to be fixed.<br>
4. People writing code that needs to support multiple versions of<br>
Python probably won't benefit, as they'll have to avoid the feature.<br>
But they will pay costs:<br>
  a) They need to review that decision over time - is the new feature<br>
compelling enough that we should drop support for older versions yet?<br>
  b) If there's an existing way of writing the construct, why ever<br>
change to the new version at all?<br>
  c) PRs written by people used to the new feature will need reviewing<br>
and fixing for compatibility.<br>
5. People not interested in the new feature will encounter it in other<br>
people's code and will need to understand it.<br>
6. Someone has to code it. It's often not at all clear whether the<br>
proposer is offering to spend the time implementing the feature, and<br>
we typically don't bluntly say "well, will you write the code?" both<br>
because it's a bit aggressive, and also because an answer of "yes"<br>
isn't enough by itself - so we don't want to mislead people that the<br>
*only* problem is finding someone to code the change.<br>
<br>
There's probably others that I have missed.<br>
<br>
In addition, there's a couple of other points, not directly related to<br>
cost but still downsides of new features:<br>
<br>
1. People need to be able to search for the new feature and learn it.<br>
For syntax in particular, that's hard, as you can't search for<br>
something unless you know the right terms. Often a library function is<br>
better than syntax for precisely this reason.<br>
2. If a new syntax is defined as "equivalent to XXX which is how you<br>
write it now", then (a) it immediately violates the "there should be<br>
one obvious way to do it" rule, *unless* the new syntax is so<br>
compelling as to immediately be seen as the new "obvious" way to do<br>
things. And (b) the people having to support older versions of Python<br>
(i.e. a *lot* of people) have no incentive to use the new construct<br>
because then they'd have to drop support for existing Python versions.<br>
<br>
Now, none of the above are insurmountable. We do get new syntax<br>
features - and they aren't always massive like async or typing.<br>
Unpacking generalisations and f-strings are recent new syntax. But you<br>
have to have a *really* good story in terms of benefits to pass the<br>
bar. And that means a lot more than just "most people on the list<br>
weren't actively against it" in the case of a proposal that's already<br>
been made and rejected.<br>
<br>
Regarding your other points, it *is* hard for newcomers to know what's<br>
an old idea. We do what we can (even to the extent of sometimes<br>
recommending PEPs just so that ideas can be formally rejected for<br>
reference) but not everyone reads up on the history, and we try to be<br>
forgiving of that. Your original post showed that you had done some<br>
research, so thanks for that. Hopefully, we can work on clarifying for<br>
people like you why the "it keeps coming up" argument isn't sufficient<br>
by itself.<br>
<br>
As regards "it will take less time in the end to implement it", if<br>
only that were true :-) Sadly, most of the people contributing to<br>
discussions here (and even though I'm a core dev, I include myself<br>
here) don't actually write code for the Python core that often -<br>
whether because time to write emails is easier to find than time to<br>
code, or for other reasons, isn't that important. So even we were all<br>
to spend a week off from Python-ideas, that wouldn't necessarily<br>
translate into new patches for Python.<br>
<br>
I hope that puts the discussion into context.<br>
<span class="HOEnZb"><font color="#888888"><br>
Paul<br>
</font></span></blockquote></div><br></div>