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