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/
