> there has STILL been no answer to the questions of "why not > use namedtuple" and "why not use a dataclass",
The OP may not have, but I at least answered why not namedtuple? very early in the thread. the TL;DR: there are use cases for namedtuple, but if the only reason you would choose a namedtuple over a regular tuple is because you want an easy way to create a new one with one value replaced, then that's not a very compelling use case. As for "why not dataclasses?" Because dataclasses are a completely different use case and API. And far more heavyweight than a tuple You might as well ask why not a class instead of a dict? I know I, and I suspect the OP, took it as a given that there are many use-cases for tuples, so the case for that didn't need to be made. I suppose it you look at this proposal by itself, you could get the idea that replacing was the primary activity for this object, in which case, yes, it might make more sense to use a different type. But why would anyone think that? Another point: the proposed replace() does not change the tuple (of course, it can't), so even if you had a mutable type, you'd have to make a copy first, and then replace the item. BTW, datetime also has a replace() method -- similar to namedtuple._replace. So the general case for creating copies of immutable objects with one part replaced shows up in multiple contexts. Adding a method to a fundamental type in Python has a pretty high bar, and (in my entirely personal opinion) this probably won't meet that bar (am I mixing metaphors, here?). But that doesn't mean it's an XY problem, or not a reasonable idea at all, which appears to have been the tone of much of this thread. Chris A: sorry to call you out, you weren't particularly harsh, but I had expected that you, of all people, might try extra hard to keep a positive tone in responses to proposals like this. and no sample code provided. Yeah, real genuine use cases would be good. For my part, I have a very clear recollection of needing this functionality, and writing a solution, and feeling a bit frustrated that is wasn't as easy as I'd like. But I don't remember off the top of my head which code base(s) that was in. Have I done it more than once? absolutely. Hundreds of times? no. Dozens? maybe. Enough to take the time to write a utility function? No. If this was my idea, I'd go and try to dig out examples from my own code. However, sample code is a bit tricky -- it seems the debate here is whether there are use cases for this functionality where using another tyoe wouldn't be a better solution -- but that requires a lot more than a snippet of code -- you'd have to look at the whole system -- I suppose one could show a small snipet, and then say that, e.g. in other contexts these tuples are used as keys in a dict, for instance, oh and also used as a Sequence, oh, and also I have millions of them at once, so don't want the overhead of a namedtuple. But I don't think the threshold should be "you can't use another type", it should simply be that a tuple is an appropriate tool. But back to my point above: there are many reasonable uses for tuples, and while, I think, ALL of them could be replaced by namedtuples, if the only reason you'd want a named tuple is to get the replace functionally, then I would never recommend that refactoring. Anyway -- despite a not-great tone, I think the conversation has been at least a little productive. The OP should have an idea what they need to do if they really want to push this forward. And persuading this list is not what needs to be done. BTW: I'm not suggesting that it's a bad idea to be discouraging: getting something even seemingly small into Python is a lot of work, and is often not successful. Giving proposers an honest assessment of their chances is the kind thing to do. But there is a very big difference in tone between: "This is a small thing, and I don't think it's likely to be accepted" and "This is not a good idea at all" And it feels (to me anyway) like there was quite a bit of the latter in this thread. So no, I don't see it as ironic. The only difference is that, here, I > wouldn't lament the thread just dying. > Careful there -- it seems you are basing this on whether you personally find the idea compelling. I would think we'd be more likely for the best ideas to get done if we strike a more welcoming, positive tone for all ideas, not just the ones we like at first glance. -CHB
_______________________________________________ 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/J27BJFHZL3QA3FUNKDU7EWZUWV4OS6OX/ Code of Conduct: http://python.org/psf/codeofconduct/
