On Mon, Mar 14, 2022 at 04:38:48PM +0000, wfdc wrote: > > I would think that at least is obvious: the top voted Python > > question on StackOverflow currently has 11891 votes. This is two > > orders of magnitude less. > > Like I said, this puts it in the top 3031 / 1908740 = 0.00159 = 0.159% > of Python questions by vote count. > > That's not "a low number of votes" no matter how you try to spin it.
It doesn't matter whether it is the top 0.159% or the top 0.00000001%, 160 votes or so is an objectively low number compared to the top ranking questions, with almost 100 times as many votes. Not that it matters. Even if the question had a trillion votes, that alone is not sufficient to justify the proposal. > > Popularity on StackOverflow is just a vague indication of > > popularity, not a sign of need or usefulness. > > Then see > > https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29%5Cs*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs*1%5Cs*:%5Cs*%5C%5D&patternType=regexp > > https://sourcegraph.com/search?q=context:global+lang:python+%3D%5Cs*list%5C%28%5B%5Cw%5C.%5D%2B%5C%29%5Cs*%5Cw%2B%5C%5B%5Cw%2B%5C%5D%5Cs*%3D%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%3D%5Cs*tuple%5C%28%5Cw%2B%5C%29&patternType=regexp > > for plenty more examples. I got "No results matched your query" on the second URL, at which point I didn't bother with the first. Thank you for providing some search terms, but you misunderstand the process of proposing new functionality to the builtins and stdlib. The onus is not on *us* to do the work, but for those making the proposal. If we ask for examples, we expect you to do the work of curating some good examples, not just to dump a regex in our laps and tell us to search for them ourselves. The bottom line here is that we don't have to justify why the proposal isn't accepted. New feature requests are not Default Accept. All we need to do is *nothing at all* and the proposal doesn't go ahead. At this point, I don't think this discussion on Python-Ideas is going anywhere, which is a shame because I actually do like it. Those who are opposed to changes (whether for good reasons or bad) are dominating the discussion. You aren't going to change their mind. Those who are neutral or in favour have had their voices drowned out. We've already had the mailing list put into Emergency Moderation once, presumably because tempers are getting frayed. I think that your strategies here could include: (1) Give this up as a lost cause. (2) Ignore the negative feedback here and raise it as an enhancement request on the bug tracker, or a PR on the repo. You will *probably* have it rejected and be told to discuss it on Python-Ideas, but you might be lucky and get the interest of a core developer who loves this proposal and accepts it. (But probably not.) (3) Look for some fresh feedback, hopefully (from your perspective) less conservative and negative. Try the "Ideas" topic on Discus. Take into account the feedback you have already received. We've told you the sorts of things that the core devs and Steering Council will be looking for. If you're not willing to provide that, you'll get the same response. Python is a mature language, and the core developers and Steering Council are conservative when it comes to adding marginally useful features that aren't obvious Big Wins, and this is not a Big Win, it is at best a Small Win. This post from one of the core devs may help you understand the culture here: https://www.curiousefficiency.org/posts/2011/04/musings-on-culture-of-python-dev.html My advice to you is that if your time and care factor is low, save your energy for battles you *really* care about. We all want what is best for Python, we may just disagree on what the balance of pros and cons are. If your care factor is high, and you want to continue gathering support for the proposal with the intention of writing a PEP, then listen to those of us who have written successful PEPs in the past. > See also the "batteries included" point that was made ages ago. (If > users find themselves re-implementing the same utility function over > and over again across different projects, it's a good sign that such a > function should be part of the standard library.) It is a sign, but how strong a sign is open for debate. My perspective is that replacement of an item in a tuple is *so simple* that it isn't even worth a utility function unless it is generalised. Just build a new tuple using slicing and concatenation expressions. Not every expression is worth an actual named function. I feel that this proposal is *too small* to bother with a function, let alone adding it to the tuple as a builtin method. But generalising it to all sequences, not just tuples, that interests me more. I've used this on strings and lists, probably more often than on tuples. Yes, it raises the bar for acceptance, but it also raises the benefit. > Your other questions are frankly not necessary to answer and feel like > goalpost-moving. The two proposals you held up as examples don't even > satisfy them. It isn't clear to me what other questions you are referring to. -- Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/P4UZ6NFTSPVLMPQSFTYB2GMJBGZXXR7Q/ Code of Conduct: http://python.org/psf/codeofconduct/
