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/
