> 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. > 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. > Is this part of the tuple class alone? > Or part of the Sequence ABC? Why or why not? Tuple alone, but I'm open to the latter. > What arguments does it take (index, slice, tuple of indicies)? Index, as specified in the OP. (Again, open to discussion.) > Any error conditions, what exceptions will be raised? I suggest raising an IndexError when the index is out of range. > Can we use it to delete an item (replace it with nothing at all)? No. > justification for why a simple one-line function isn't sufficient. See Christopher Barker's response. (Yes, efficiency is important.) 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.) 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. ------- Original Message ------- On Monday, March 14th, 2022 at 8:32 AM, Steven D'Aprano <st...@pearwood.info> wrote: > On Fri, Mar 11, 2022 at 07:12:49PM +0000, wfdc via Python-ideas wrote: > > > > one Stack Overflow question, with a low number of votes > > > > Mind explaining why you say 159 is a "low number of votes" for a > > > > StackOverflow question on Python? > > 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. > > It is certainly true that there are over a million Python questions that > > have received even fewer votes, but 159 votes is still low. > > In any case, number of votes on StackOverflow is not a good way of > > judging the worth of a proposal. Votes can be given for many reasons, > > not just "this proposal should be a built-in function or method". For > > example, the highest voted question is a request for an explanation, > > "What does the yield keyword do?". > > Popularity on StackOverflow is just a vague indication of popularity, > > not a sign of need or usefulness. > > > > And yet you haven't demonstrated that this is the case for your > > > > > > proposal > > > > What kind of evidence would satisfy you? And how did previous > > > > proposals you supported obtain such evidence? > > Excellent question! > > Unfortunately, I think this is a non-trivial change that will require > > a PEP. > > (The boundary between trivial and non-trivial is subjective, and others > > may disagree, but here I feel confident that the core devs will agree > > that regardless of how trivial the implementation, a change to the API > > of a core builtin type like tuple will require a PEP.) > > Yes, this is a lot of trouble to go through, but Python is a 30+ year > > old mature language. Even though this change alone is not breaking > > backwards compatibility, it still has consequences. Every change has to > > justify itself, every feature has costs: > > - extra code in the interpreter > > - more things that can break > > - extra tests > > - more documentation > > - more for users to learn > > - more to remember > > What may be my essential feature may be your bloat. > > If the benefits don't outweigh the costs for the majority of people, > > then the proposal is unlikely to be accepted. > > You should start by looking at similar successful PEPs, e.g.: > > Dict union: https://peps.python.org/pep-0584/ > > String methods to remove prefixes and suffixes: > > https://peps.python.org/pep-0616/ > > and maybe some unsuccessful ones as well. > > By the way, when I started writing PEP 584, it was with the intention > > that the PEP be rejected once and for all, so we could have a place to > > point people at when they wanted to know what they can't add dicts. Only > > it turned out that the case for dict "addition" (dict union) was > > stronger than anyone thought, and the PEP was accepted. > > Once you have at least the skeleton of a PEP, you need to find a core > > developer who thinks it is promising enough to sponsor it. If you can't > > convince even one single core dev that this proposal has promise, then > > it is dead in the water. > > If this was my proposal, I would want to provide a full specification of > > the API: > > - Is this part of the tuple class alone? > > - Or part of the Sequence ABC? Why or why not? > > - What arguments does it take (index, slice, tuple of indicies)? > > - Any error conditions, what exceptions will be raised? > > - Can we use it to delete an item (replace it with nothing at all)? > > I would want to include: > > - an overview of what other programming languages provide this and the > > APIs they use; > > - and any third-party libraries and classes; > > - and any builtins and stdlib classes (you already have one, namedtuple); > > - places in the stdlib that could use this functionality; > > - examples of your own code where you would use it; > > - justification for why a simple one-line function isn't sufficient. > > The last is probably the hardest. We're not immune to efficiency > > arguments, but generally we don't care about minor inefficiencies. > > -- > > 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/OHNNKOPEVAVHTCWMX6Y2R3RXB2WBHI5G/ > > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ 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/PEC6PLMOD5YTZSZVKE4USG3ME7GEVUST/ Code of Conduct: http://python.org/psf/codeofconduct/
