> the "not every one-line function needs to be a builtin" principle applies > here, in my view.
The "not every one-line function needs to *not* be a builtin" principle cancels it out. And the "frequently-used functionality should be built-in" (Python's "batteries included" philosophy) overrides it. > you hadn't demonstrated that your proposal satisfied the criteria that you > yourself stated How so? > proposals that succeeded often did so by surveying significant bodies of > real-world code (for example, the standard library) and pointing out where > the proposed new feature would demonstrably improve the readability or > maintainability of parts of the code. That's something we can work with. Do you have particular examples that demonstrate the kind of evidence that would satisfy you? > You do know how many people use Python? 2 people saying they do something like this isn't particularly significant. That's strawmanning my point. I said 2 participants *in this thread*. That's a very different population being sampled from to assess significance than "the entire population of Python users". > Even 2 people out of the number of regular contributors on python-ideas isn't > a lot Again, *in this thread*. > especially if you take level of participation into account - which is dangerous, because it amounts to an appeal to authority I don't see how "it amounts to an appeal to authority". Can you explain? Furthermore, the StackOverflow page provides additional evidence that this functionality is in demand. And it's not just the question itself, but the upvotes, answers, and comments on that page. > Why, in the context of that real-world problem, is a tuple (as opposed to, > say, an immutable dataclass or namedtuple, both of which have replace > methods) the demonstrably best choice, *in spite* of the fact that other > choices provide the supposedly important replace functionality? See Christopher Barker's reply to Chris Angelico. See also my reply to Chris Angelico. > The original SO question sounds suspiciously like an XY-problem to me (see https://en.wikipedia.org/wiki/XY_problem). On what basis? And again, it's not just the question itself, but the upvotes, answers, and comments on that page. > I understand *what* you want. But *why*? See my reply to Chris Angelico. ------- Original Message ------- On Friday, March 11th, 2022 at 2:54 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > On Fri, 11 Mar 2022 at 19:12, wfdc w...@protonmail.com wrote: > > > What kind of evidence would satisfy you? And how did previous proposals you > > supported obtain such evidence? > > Honestly, probably nothing. I don't think this is a good idea in any > > case, the "not every one-line function needs to be a builtin" > > principle applies here, in my view. You may have a different view, > > that's fine. My reason for pointing out that you hadn't demonstrated > > that your proposal satisfied the criteria that you yourself stated, is > > that you might find someone more sympathetic to the proposal, and if > > so, this is the sort of evidence that you'd need in order to take this > > to python-dev or to create a PR, if you were to have any chance of > > success. > > In the past, proposals that succeeded often did so by surveying > > significant bodies of real-world code (for example, the standard > > library) and pointing out where the proposed new feature would > > demonstrably improve the readability or maintainability of parts of > > the code. > > > We've already had 2 other participants here attesting to frequent use of > > this functionality. > > You do know how many people use Python? 2 people saying they do > > something like this isn't particularly significant. Even 2 people out > > of the number of regular contributors on python-ideas isn't a lot > > (especially if you take level of participation into account - which is > > dangerous, because it amounts to an appeal to authority, but how else > > are you going to demonstrate that a non-trivial number of the millions > > of people who use Python would find this helpful? > > > > it's not clear that the OP shouldn't have been using a list in > > > > > > the first place > > > > This has already been explained in this thread. A list is not immutable. A > > tuple is. Both the old and new tuples are not mutated or mutable, and we > > want to keep it that way. > > Yes, I understand that if you want to create a new immutable tuple > > with one value changed, you need to build it from the parts of the > > original. But there's no context here. What's the real-world problem > > being solved? Why, in the context of that real-world problem, is a > > tuple (as opposed to, say, an immutable dataclass or namedtuple, both > > of which have replace methods) the demonstrably best choice, in > > spite of the fact that other choices provide the supposedly important > > replace functionality? > > The original SO question sounds suspiciously like an XY-problem to me > > (see https://en.wikipedia.org/wiki/XY_problem). > > > See namedtuple's ._replace method. namedtuples are also immutable. We > > simply want the same functionality for tuple. > > I understand what you want. But why? If the only reason is "for > > consistency", then fine, that's a reasonable reason. Unlikely to be > > sufficient in isolation, but that's OK. You asked, you got told "your > > reasons aren't sufficient". But if you want to persuade someone who > > has the ability to commit a change to Python to support this proposal, > > you'll need more (which is what I am trying to help you with). > > Best of luck in trying to get support for this idea. I'm not keen on > > it myself, but I'm grateful that you're willing to spend time helping > > to contribute back towards improving Python. > > Paul > > _______________________________________________ > > 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/QOFB34UYWF5K7WPSTMTDPQSLH7VYBC5G/ > > 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/3VKQZAZIMLXXTYVVVGBKFYFNEHWLQI2M/ Code of Conduct: http://python.org/psf/codeofconduct/
