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/
