Re: Add a replace method to tuples
why haven't you used a list
1. A list is not immutable. 2. I don't want to modify the original sequence. ------- Original Message ------- On Friday, March 11th, 2022 at 4:07 PM, Marco Sulla <Marco.Sulla.Python@gmail.com> wrote:
On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas <python-ideas@python.org> wrote: > > why haven't you used a list > 2. I don't want to modify the original sequence. > There's a really easy solution for you that will even be more perfomant. Use a list and DON'T modify the original! This is ABSOLUTELY an XY-problem.... which fact was difficult to wrestle out of you. >>> stuff1 = [a, b, c, d] >>> stuff2 = stuff1[:] >>> stuff2[2] = e
Don't yell. You just effectively re-implemented Christopher Barker's solution (which was also present in the StackOverflow thread), with the downside that it fails the immutability criterion. Saying "just be careful not to mutate the original datastructure" isn't a solution. There's a reason we have immutable types: To enforce immutability. Otherwise, why aren't you proposing getting rid of the tuple type entirely? ------- Original Message ------- On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. <david.mertz@gmail.com> wrote: > On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas <python-ideas@python.org> wrote: > >>> why haven't you used a list >> 2. I don't want to modify the original sequence. > > There's a really easy solution for you that will even be more perfomant. > > Use a list and DON'T modify the original! > > This is ABSOLUTELY an XY-problem.... which fact was difficult to wrestle out of you. > >>>> stuff1 = [a, b, c, d] >>>> stuff2 = stuff1[:] >>>> stuff2[2] = e
So it appears the "problem" this is intended to solve is "Python isn't Haskell." But Haskell exists, and this is a non-problem looking for a solution. On Fri, Mar 11, 2022, 4:39 PM wfdc <wfdc@protonmail.com> wrote: > Don't yell. > > You just effectively re-implemented Christopher Barker's solution (which > was also present in the StackOverflow thread), with the downside that it > fails the immutability criterion. > > Saying "just be careful not to mutate the original datastructure" isn't a > solution. There's a reason we have immutable types: To *enforce* > immutability. Otherwise, why aren't you proposing getting rid of the tuple > type entirely? > > ------- Original Message ------- > On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. < > david.mertz@gmail.com> wrote: > > On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas < > python-ideas@python.org> wrote: > >> > why haven't you used a list >> 2. I don't want to modify the original sequence. >> > > There's a really easy solution for you that will even be more perfomant. > > Use a list and DON'T modify the original! > > This is ABSOLUTELY an XY-problem.... which fact was difficult to wrestle > out of you. > > >>> stuff1 = [a, b, c, d] > >>> stuff2 = stuff1[:] > >>> stuff2[2] = e > > > >
Wrong. If you're not willing to make substantive contributions to this thread, I suggest you refrain from posting further. ------- Original Message ------- On Friday, March 11th, 2022 at 4:42 PM, David Mertz, Ph.D. <david.mertz@gmail.com> wrote: > So it appears the "problem" this is intended to solve is "Python isn't Haskell." > > But Haskell exists, and this is a non-problem looking for a solution. > > On Fri, Mar 11, 2022, 4:39 PM wfdc <wfdc@protonmail.com> wrote: > >> Don't yell. >> >> You just effectively re-implemented Christopher Barker's solution (which was also present in the StackOverflow thread), with the downside that it fails the immutability criterion. >> >> Saying "just be careful not to mutate the original datastructure" isn't a solution. There's a reason we have immutable types: To enforce immutability. Otherwise, why aren't you proposing getting rid of the tuple type entirely? >> >> ------- Original Message ------- >> On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. <david.mertz@gmail.com> wrote: >> >>> On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas <python-ideas@python.org> wrote: >>> >>>>> why haven't you used a list >>>> 2. I don't want to modify the original sequence. >>> >>> There's a really easy solution for you that will even be more perfomant. >>> >>> Use a list and DON'T modify the original! >>> >>> This is ABSOLUTELY an XY-problem.... which fact was difficult to wrestle out of you. >>> >>>>>> stuff1 = [a, b, c, d] >>>>>> stuff2 = stuff1[:] >>>>>> stuff2[2] = e
This is a common scenario on python-list or python-ideas: Someone has an idea that they think is the greatest thing since sliced bread. They propose it, and feel hurt / rejected when they get pushback instead of everyone jumping up and down and saying how brilliant it is. Sometimes they are downright rude. I wouldn't say you've quite crossed that line, but your tone certainly comes across (to me at least) as belligerent. It won't help your cause to put people's backs up. I apologise if that's not how you meant it. Of course occasionally someone comes up with a really good idea. But most proposals fail to gain traction because they are actually not a very good idea, or there is not enough support for them, or simply because no-one is prepared to put in the effort (e.g. to write a PEP and/or make a reference implementation, etc.) The default position is "status quo wins" because there is a cost for every feature added. It has to be implemented. Tests have to be written for it. It has to be maintained. The online documentation has to be updated. Many books on Python become out of date until/unless the authors (if still alive) can update them. It's one more thing that people (may) have to learn when they learn Python. Net result: quite a high bar for changes (even small ones). Even on the (few) occasions when someone has a really good, new idea, they may have to spend time patiently arguing for it, answering objections, demonstrating use cases, covering corner cases, discussing alternatives/variations etc. before their idea gains support. My opinion on it's own counts for nothing. I'm not even saying your proposal is a bad idea. But it seems to me that something you can implement as a 1-liner in your own code is hardly a pressing need. I wasn't aware of namedtuple's _.replace method. But as far as I can see, the API is not the same as your proposed method either. Quoting from https://stackoverflow.com/questions/2166147/namedtuple-replace-doesnt-work-a... : |
|There is no index (0, 1, 2 ...), instead there is a name. | On 11/03/2022 21:43, wfdc via Python-ideas wrote:
Do you see why it's useful to have immutability? Best wishes Rob Cliffe
they may have to spend time patiently arguing for it, answering objections, demonstrating use cases, covering corner cases, discussing alternatives/variations etc.
That's what I'm doing. A direct writing style does not mean "belligerent".
But it seems to me that something you can implement as a 1-liner in your own code is hardly a pressing need.
1. As Christopher Barker and Marco Sulla pointed out, it's not the most efficient implementation. The latter may be more elaborate. It's worth exploring further. 2. Regardless of whether it's a 1-liner (like the existing count method), if a function is used frequently, it's worth considering as an addition to the standard library. This saves users from having to reimplement the same utility function again and again across projects, possibly making errors in the process.
I wasn't aware of namedtuple's _.replace method. But as far as I can see, the API is not the same as your proposed method either.
I raised it as an example of modifying an immutable type. The exact API of the proposed method is open to discussion.
That, it seems to me, is a pretty insulting thing to say
Not at all. It's appropriate given the tone and content of the post it's addressed to.
to someone who, I would guess, has been using Python for decade(s) longer than you have.
1. On what basis? You don't know who I am. 2. How long they've been using Python is irrelevant. It's also strange to bring up the Python-age of participants after protesting appeal to authority.
Likewise this which you wrote in another post: "Do you see why it's useful to have immutability?"
That's not insulting at all. It's a perfectly valid question to address to a post that seems to be contesting the purpose of immutable types in the first place. ------- Original Message ------- On Friday, March 11th, 2022 at 5:38 PM, Rob Cliffe <rob.cliffe@btinternet.com> wrote:
On Fri, Mar 11, 2022, 6:19 PM wfdc <wfdc@protonmail.com> wrote:
Gosh, I had no idea immutability could be useful! :-) https://openlibra.com/en/book/functional-programming-in-python
Now read what you said earlier:
So it appears the "problem" this is intended to solve is "Python isn't Haskell."
But Haskell exists, and this is a non-problem looking for a solution.
A bizarre incongruence, right? ------- Original Message ------- On Friday, March 11th, 2022 at 6:26 PM, David Mertz, Ph.D. <david.mertz@gmail.com> wrote:
On Fri, Mar 11, 2022 at 06:26:52PM -0500, David Mertz, Ph.D. wrote:
Aren't you the same David Mertz who earlier insisted that wfdc is Doing It Wrong for using tuples when he should be using lists? https://mail.python.org/archives/list/python-ideas@python.org/message/LZAWS3... -- Steve
(To be clear, I'm saying David Mertz's proposal fails the immutability criterion, not Christopher Barker's.) ------- Original Message ------- On Friday, March 11th, 2022 at 4:39 PM, wfdc <wfdc@protonmail.com> wrote: > Don't yell. > > You just effectively re-implemented Christopher Barker's solution (which was also present in the StackOverflow thread), with the downside that it fails the immutability criterion. > > Saying "just be careful not to mutate the original datastructure" isn't a solution. There's a reason we have immutable types: To enforce immutability. Otherwise, why aren't you proposing getting rid of the tuple type entirely? > > ------- Original Message ------- > On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. <david.mertz@gmail.com> wrote: > >> On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas <python-ideas@python.org> wrote: >> >>>> why haven't you used a list >>> 2. I don't want to modify the original sequence. >> >> There's a really easy solution for you that will even be more perfomant. >> >> Use a list and DON'T modify the original! >> >> This is ABSOLUTELY an XY-problem.... which fact was difficult to wrestle out of you. >> >>>>> stuff1 = [a, b, c, d] >>>>> stuff2 = stuff1[:] >>>>> stuff2[2] = e
Yes. To be clear, immutability isn't a use case, it's a particular technique that can be useful for solving some problems. This is probably a clear enough example of the XY-problem as to be worth adding to the Wikipedia article on that topic. We sometimes see other similar proposals to e.g. "solve" the "problem" that Python isn't statically typed. That is, folks who want Python to be some different language. On Fri, Mar 11, 2022, 4:42 PM wfdc <wfdc@protonmail.com> wrote: > (To be clear, I'm saying David Mertz's proposal fails the immutability > criterion, not Christopher Barker's.) > > ------- Original Message ------- > On Friday, March 11th, 2022 at 4:39 PM, wfdc <wfdc@protonmail.com> wrote: > > Don't yell. > > You just effectively re-implemented Christopher Barker's solution (which > was also present in the StackOverflow thread), with the downside that it > fails the immutability criterion. > > Saying "just be careful not to mutate the original datastructure" isn't a > solution. There's a reason we have immutable types: To *enforce* > immutability. Otherwise, why aren't you proposing getting rid of the tuple > type entirely? > > ------- Original Message ------- > On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. < > david.mertz@gmail.com> wrote: > > On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas < > python-ideas@python.org> wrote: > >> > why haven't you used a list >> 2. I don't want to modify the original sequence. >> > > There's a really easy solution for you that will even be more perfomant. > > Use a list and DON'T modify the original! > > This is ABSOLUTELY an XY-problem.... which fact was difficult to wrestle > out of you. > > >>> stuff1 = [a, b, c, d] > >>> stuff2 = stuff1[:] > >>> stuff2[2] = e > > > > >
So do you propose getting rid of the tuple type entirely or not? Do you see why it's useful to have immutability? ------- Original Message ------- On Friday, March 11th, 2022 at 4:47 PM, David Mertz, Ph.D. <david.mertz@gmail.com> wrote: > Yes. To be clear, immutability isn't a use case, it's a particular technique that can be useful for solving some problems. > > This is probably a clear enough example of the XY-problem as to be worth adding to the Wikipedia article on that topic. > > We sometimes see other similar proposals to e.g. "solve" the "problem" that Python isn't statically typed. That is, folks who want Python to be some different language. > > On Fri, Mar 11, 2022, 4:42 PM wfdc <wfdc@protonmail.com> wrote: > >> (To be clear, I'm saying David Mertz's proposal fails the immutability criterion, not Christopher Barker's.) >> >> ------- Original Message ------- >> On Friday, March 11th, 2022 at 4:39 PM, wfdc <wfdc@protonmail.com> wrote: >> >>> Don't yell. >>> >>> You just effectively re-implemented Christopher Barker's solution (which was also present in the StackOverflow thread), with the downside that it fails the immutability criterion. >>> >>> Saying "just be careful not to mutate the original datastructure" isn't a solution. There's a reason we have immutable types: To enforce immutability. Otherwise, why aren't you proposing getting rid of the tuple type entirely? >>> >>> ------- Original Message ------- >>> On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. <david.mertz@gmail.com> wrote: >>> >>>> On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas <python-ideas@python.org> wrote: >>>> >>>>>> why haven't you used a list >>>>> 2. I don't want to modify the original sequence. >>>> >>>> There's a really easy solution for you that will even be more perfomant. >>>> >>>> Use a list and DON'T modify the original! >>>> >>>> This is ABSOLUTELY an XY-problem.... which fact was difficult to wrestle out of you. >>>> >>>>>>> stuff1 = [a, b, c, d] >>>>>>> stuff2 = stuff1[:] >>>>>>> stuff2[2] = e
On Sat, 12 Mar 2022 at 08:53, wfdc via Python-ideas <python-ideas@python.org> wrote:
So do you propose getting rid of the tuple type entirely or not?
Do you see why it's useful to have immutability?
Immutability is extremely useful. I use tuples VERY frequently. But I don't then need to replace one element in them. ChrisA
You may not, but others do. 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 and 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 ------- Original Message ------- On Monday, March 14th, 2022 at 8:31 AM, Chris Angelico <rosuav@gmail.com> wrote:
Wow! Does anyone else see the irony in the fact that just a couple days ago, Chris A lamented that Python-ideas seemed to Immediately reject any new idea out of hand? And yes, Chris, you have joined in the piling on in this case. I didn’t think it was that bad, but this thread has been pretty painful. I’m pretty surprised that folks seem to be denying that this proposal has any use at all. Is this a major need? Obviously not, As for “not every one line function..” I demonstrated quite clearly that its not a one liner, it’s not obvious, and as Marco pointed out, it literally has to be a built in to get top performance. Is the SC likely to think it’s worth adding a new method to a core built in for? Probably not. But not rising to the very high standard that changes to core Python need is not the same as a pointless or bad idea. Thanks Paul for laying out what would have to be done honestly. To rest of you Debbie Downers -. Really? -CHB On Fri, Mar 11, 2022 at 1:51 PM wfdc via Python-ideas < python-ideas@python.org> wrote: > So do you propose getting rid of the tuple type entirely or not? > > Do you see why it's useful to have immutability? > > ------- Original Message ------- > > On Friday, March 11th, 2022 at 4:47 PM, David Mertz, Ph.D. < > david.mertz@gmail.com> wrote: > > Yes. To be clear, immutability isn't a use case, it's a particular > technique that can be useful for solving some problems. > > This is probably a clear enough example of the XY-problem as to be worth > adding to the Wikipedia article on that topic. > > We sometimes see other similar proposals to e.g. "solve" the "problem" > that Python isn't statically typed. That is, folks who want Python to be > some different language. > > > On Fri, Mar 11, 2022, 4:42 PM wfdc <wfdc@protonmail.com> wrote: > >> (To be clear, I'm saying David Mertz's proposal fails the immutability >> criterion, not Christopher Barker's.) >> >> ------- Original Message ------- >> On Friday, March 11th, 2022 at 4:39 PM, wfdc <wfdc@protonmail.com> wrote: >> >> Don't yell. >> >> You just effectively re-implemented Christopher Barker's solution (which >> was also present in the StackOverflow thread), with the downside that it >> fails the immutability criterion. >> >> Saying "just be careful not to mutate the original datastructure" isn't a >> solution. There's a reason we have immutable types: To *enforce* >> immutability. Otherwise, why aren't you proposing getting rid of the tuple >> type entirely? >> >> ------- Original Message ------- >> On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. < >> david.mertz@gmail.com> wrote: >> >> On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas < >> python-ideas@python.org> wrote: >> >>> > why haven't you used a list >>> 2. I don't want to modify the original sequence. >>> >> >> There's a really easy solution for you that will even be more perfomant. >> >> Use a list and DON'T modify the original! >> >> This is ABSOLUTELY an XY-problem.... which fact was difficult to wrestle >> out of you. >> >> >>> stuff1 = [a, b, c, d] >> >>> stuff2 = stuff1[:] >> >>> stuff2[2] = e >> >> >> >> >> > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-leave@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/K3CWHSBWAA5PANVV44CVQPDVEAIYAJ7N/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
Just to add, the following Sourcegraph queries provide good evidence of widespread use of this functionality: 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 ------- Original Message ------- On Saturday, March 12th, 2022 at 1:41 AM, Christopher Barker <pythonchb@gmail.com> wrote:
On Mon, 14 Mar 2022 at 23:54, Christopher Barker <pythonchb@gmail.com> wrote:
There definitely is a problem when my post, which was asking for more details, can be seen as merely piling on the criticism. It indicates that there is so much criticism that everything starts to look like it. In this particular thread, the OP certainly isn't helping to solve the issue, as there has STILL been no answer to the questions of "why not use namedtuple" and "why not use a dataclass", and no sample code provided. But yes, when the dogpile gets so big that every post looks like more dogpiling, there is a bit of a problem. So no, I don't see it as ironic. The only difference is that, here, I wouldn't lament the thread just dying. ChrisA
there has STILL been no answer to the questions of "why not use namedtuple" and "why not use a dataclass"
Christopher addressed that a long time ago.
no sample code provided
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 ------- Original Message ------- On Monday, March 14th, 2022 at 8:56 AM, Chris Angelico <rosuav@gmail.com> wrote:
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
On Tue, 15 Mar 2022 at 05:37, Christopher Barker <pythonchb@gmail.com> wrote:
My apologies. The thread has gotten VERY noisy, and I did miss the fact that you'd said this; partly because the OP has only had arguments like "namedtuples aren't sequences", which are not what I'd call compelling. I still stand by the sentiment that sample code from the OP is more important than someone else's explanation of why namedtuple might not be suitable, but perhaps the OP sees it as an answered question. I've been keeping the tone as positive as possible, but honestly, I don't think this thread has much hope of being productive at this point, and if you hadn't called me out specifically, I would not have responded. ChrisA
the OP has only had arguments like "namedtuples aren't sequences", which are not what I'd call compelling.
Why don't you answer the question I asked you? ------- Original Message ------- On Monday, March 14th, 2022 at 4:12 PM, Chris Angelico <rosuav@gmail.com> wrote:
Travel Portal Development We have a devoted group of engineers bringing unparalleled experience and information to the table for the clients, a one of a kind travel gateway that will certainly speed up the brand or business. https://www.flightapis.com/travel-portal-development
Game theorist here. wfdc via Python-ideas writes:
Do you see why it's useful to have immutability?
Sure, it's potentially hashable. But I can't recall ever finding that useful in working with matrix games (loosely speaking, I mean games with a finite set of players, each with a finite strategy space). I've used (subclasses of) tuple for strategy profiles, but I always wanted more additional attributes than just 'replace' (thus subclasses), and I call it "deviate" (usually) or "disturbance" (when computing perfect or proper equilibria; of course those implicate the mixed extension, which complicates thing, and also they involve changing all the non-interior strategies simultaneously). Really curious to hear enough about your use case to understand why adding this method to tuple is so much preferable to using a list (which is what I do when calculating best replies in an abstract matrix game, eg toy examples for introductory classes) or some class based on dict, list, or tuple (when the game is a model of some social phenomenon and I want to access various summaries of performance "at" a profile).
You are, and you have every right to. I want to talk about immutable sequences, and that's fine, too. The point is that str and tuples are both immutable sequences, and both "replace at index" and "replace value" make sense for all sequences. Of course mutable sequences already have the usual indexing and slicing APIs for replacement, so this would be immutables only. BTW, bytes.replace has the same signature as str.replace. It's true that namedtuple has a replace method with a different signature, but that signature relates to namedtuple as a (general) *mapping*, not as a *sequence* (which, although it's a special case of mapping, is sufficiently important to have two builtin implementations).
True. I wouldn't expect the replace method on ints to be the same as the replace method on tuples. I would expect the replace method on immutable sequences to be consistent across subtypes. I don't yet see a reason why "replace value" wouldn't be at least as useful "replace at index". And in fact "replace value" is plausible for list, as well, with that signature. Based on the precedent set by other immutable sequences, I'm firmly -1 on the name "replace" for "replace at". I'm -1 on adding it to tuple with any name, but I could be convinced otherwise based on systematic evidence that it's broadly useful, such as a survey of the stdlib. Steve
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 and 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 ------- Original Message ------- On Sunday, March 13th, 2022 at 1:55 AM, Stephen J. Turnbull <stephenjturnbull@gmail.com> wrote:
Hi, You are clearly not making progress, and this list is no longer useful to you for this idea -- you know what you want, it's easy enough to implement, and you don't need our advice for that I assume. I suggest you give up on this list, write the code, make sure it's well-documented, and submit a merge request. If you don't get a timely response (ie, after a decent interval for the relevant folks to pick up the merge request) ping python-dev directly for a decision. If you're worried about coding style or exactly how the submission process works, core-mentorship@python.org will give you help on that with a minimum of backseat driving. wfdc via Python-ideas writes:
You're going to have to work harder than that to convince me. It's not clear how many of those examples are unique, and most are concise and idiomatic. Good luck! Steve
You're going to have to work harder than that to convince me. It's not clear how many of those examples are unique, and most are concise and idiomatic.
Ridiculous goalpost-moving. I literally just gave you 1000+ examples of this functionality being used, which is what you asked for, including by several important repositories and organizations: - pytorch - pandas - apache - numpy - jax - sympy - cupy - tensorflow - pyqtgraph - aws - dask - deepmind - h5py - cloudflare - facebook research and so on. At this point, it seems like you're just trying to save face. ------- Original Message ------- On Monday, March 14th, 2022 at 9:47 AM, Stephen J. Turnbull <stephenjturnbull@gmail.com> wrote:
On Mon, Mar 14, 2022 at 04:57:09PM +0000, wfdc via Python-ideas wrote:
100 repetitions of the same dozen or so examples is no stronger evidence than just listing a dozen unique examples. wfdc, whether you like it or not, Python is not yours to change as you see fit. (Being open source, you are welcome to fork it and do whatever you want with it.) You have to not just convince others that your proposal is useful, but that it is is **useful enough** to build it into the language. It is true that much of this thread has been dominated by some extremely negative, condescending replies. But you are not helping by biting the hands of those trying to help you. You have been told the processes that you have to follow to get this change accepted into Python. Snarling and biting at us is not going to change that. I don't know how things are like in your workplace, assuming you are a professional coder, but you cannot intimidate us by snarling. You will just get muted and your emails deleted. So chill out. Enhancement requests are not Default Accept. You can try putting an enhancement request on the bug tracker, but almost certainly you will be told to propose it here to see if there is consensus that it is useful enough. You can submit a PR on the repo, but likewise. You can ask on Python-Dev, but you will almost certainly be told you need to write a PEP, and to have that PEP even accepted for consideration you need to have at least one core developer volunteer to sponsor it. You could discuss it on Discuss, where at least you are likely to get feedback from a different set of people, but the eventual answer will be the same: this almost surely will need a PEP. Yes, this is all a damn nuisance, but it is what it is and you have to work with the system we have, not the system you want. And if you think this is problematic, you should try proposing a change to the Java or C languages. -- Steve
Steven D'Aprano writes:
That's a good description of the various paths, but I don't think the bar here is as high as a PEP. I don't recall there being a PEP for zip(..., strict=). This is somewhat more invasive than that, but I really don't see a need for a PEP. The motivation is obvious, the implementation is trivial unless you want to catch edge cases like replacing an index that's out of bounds (note ()[:0] + ()[1:] => ()), but that's the only such I can think of, and that's close to trivial. The only justification I can see for a PEP would be a curated list of usages and/or description of a compelling use case. The former *would* be a PITA that wfdc is manifestly unwilling to perform. The latter is nonexistent, it's a three-line function, and that's assuming you go for overkill with argument-checking. Saying that it's been discussed on Python Ideas, and now it's ready for review, should be enough to foreclose bringing it back here. I think the likely response to a PR is summary closure, but that's the best bet. There's nothing to be learned by continuing this thread, that's for sure.
Yes, this is all a damn nuisance,
Not compared to the free-fire zones I've seen in some projects. ;-) Steve
On Thu, 17 Mar 2022 at 01:09, Stephen J. Turnbull <stephenjturnbull@gmail.com> wrote:
On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas <python-ideas@python.org> wrote: > > why haven't you used a list > 2. I don't want to modify the original sequence. > There's a really easy solution for you that will even be more perfomant. Use a list and DON'T modify the original! This is ABSOLUTELY an XY-problem.... which fact was difficult to wrestle out of you. >>> stuff1 = [a, b, c, d] >>> stuff2 = stuff1[:] >>> stuff2[2] = e
Don't yell. You just effectively re-implemented Christopher Barker's solution (which was also present in the StackOverflow thread), with the downside that it fails the immutability criterion. Saying "just be careful not to mutate the original datastructure" isn't a solution. There's a reason we have immutable types: To enforce immutability. Otherwise, why aren't you proposing getting rid of the tuple type entirely? ------- Original Message ------- On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. <david.mertz@gmail.com> wrote: > On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas <python-ideas@python.org> wrote: > >>> why haven't you used a list >> 2. I don't want to modify the original sequence. > > There's a really easy solution for you that will even be more perfomant. > > Use a list and DON'T modify the original! > > This is ABSOLUTELY an XY-problem.... which fact was difficult to wrestle out of you. > >>>> stuff1 = [a, b, c, d] >>>> stuff2 = stuff1[:] >>>> stuff2[2] = e
So it appears the "problem" this is intended to solve is "Python isn't Haskell." But Haskell exists, and this is a non-problem looking for a solution. On Fri, Mar 11, 2022, 4:39 PM wfdc <wfdc@protonmail.com> wrote: > Don't yell. > > You just effectively re-implemented Christopher Barker's solution (which > was also present in the StackOverflow thread), with the downside that it > fails the immutability criterion. > > Saying "just be careful not to mutate the original datastructure" isn't a > solution. There's a reason we have immutable types: To *enforce* > immutability. Otherwise, why aren't you proposing getting rid of the tuple > type entirely? > > ------- Original Message ------- > On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. < > david.mertz@gmail.com> wrote: > > On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas < > python-ideas@python.org> wrote: > >> > why haven't you used a list >> 2. I don't want to modify the original sequence. >> > > There's a really easy solution for you that will even be more perfomant. > > Use a list and DON'T modify the original! > > This is ABSOLUTELY an XY-problem.... which fact was difficult to wrestle > out of you. > > >>> stuff1 = [a, b, c, d] > >>> stuff2 = stuff1[:] > >>> stuff2[2] = e > > > >
Wrong. If you're not willing to make substantive contributions to this thread, I suggest you refrain from posting further. ------- Original Message ------- On Friday, March 11th, 2022 at 4:42 PM, David Mertz, Ph.D. <david.mertz@gmail.com> wrote: > So it appears the "problem" this is intended to solve is "Python isn't Haskell." > > But Haskell exists, and this is a non-problem looking for a solution. > > On Fri, Mar 11, 2022, 4:39 PM wfdc <wfdc@protonmail.com> wrote: > >> Don't yell. >> >> You just effectively re-implemented Christopher Barker's solution (which was also present in the StackOverflow thread), with the downside that it fails the immutability criterion. >> >> Saying "just be careful not to mutate the original datastructure" isn't a solution. There's a reason we have immutable types: To enforce immutability. Otherwise, why aren't you proposing getting rid of the tuple type entirely? >> >> ------- Original Message ------- >> On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. <david.mertz@gmail.com> wrote: >> >>> On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas <python-ideas@python.org> wrote: >>> >>>>> why haven't you used a list >>>> 2. I don't want to modify the original sequence. >>> >>> There's a really easy solution for you that will even be more perfomant. >>> >>> Use a list and DON'T modify the original! >>> >>> This is ABSOLUTELY an XY-problem.... which fact was difficult to wrestle out of you. >>> >>>>>> stuff1 = [a, b, c, d] >>>>>> stuff2 = stuff1[:] >>>>>> stuff2[2] = e
This is a common scenario on python-list or python-ideas: Someone has an idea that they think is the greatest thing since sliced bread. They propose it, and feel hurt / rejected when they get pushback instead of everyone jumping up and down and saying how brilliant it is. Sometimes they are downright rude. I wouldn't say you've quite crossed that line, but your tone certainly comes across (to me at least) as belligerent. It won't help your cause to put people's backs up. I apologise if that's not how you meant it. Of course occasionally someone comes up with a really good idea. But most proposals fail to gain traction because they are actually not a very good idea, or there is not enough support for them, or simply because no-one is prepared to put in the effort (e.g. to write a PEP and/or make a reference implementation, etc.) The default position is "status quo wins" because there is a cost for every feature added. It has to be implemented. Tests have to be written for it. It has to be maintained. The online documentation has to be updated. Many books on Python become out of date until/unless the authors (if still alive) can update them. It's one more thing that people (may) have to learn when they learn Python. Net result: quite a high bar for changes (even small ones). Even on the (few) occasions when someone has a really good, new idea, they may have to spend time patiently arguing for it, answering objections, demonstrating use cases, covering corner cases, discussing alternatives/variations etc. before their idea gains support. My opinion on it's own counts for nothing. I'm not even saying your proposal is a bad idea. But it seems to me that something you can implement as a 1-liner in your own code is hardly a pressing need. I wasn't aware of namedtuple's _.replace method. But as far as I can see, the API is not the same as your proposed method either. Quoting from https://stackoverflow.com/questions/2166147/namedtuple-replace-doesnt-work-a... : |
|There is no index (0, 1, 2 ...), instead there is a name. | On 11/03/2022 21:43, wfdc via Python-ideas wrote:
Do you see why it's useful to have immutability? Best wishes Rob Cliffe
they may have to spend time patiently arguing for it, answering objections, demonstrating use cases, covering corner cases, discussing alternatives/variations etc.
That's what I'm doing. A direct writing style does not mean "belligerent".
But it seems to me that something you can implement as a 1-liner in your own code is hardly a pressing need.
1. As Christopher Barker and Marco Sulla pointed out, it's not the most efficient implementation. The latter may be more elaborate. It's worth exploring further. 2. Regardless of whether it's a 1-liner (like the existing count method), if a function is used frequently, it's worth considering as an addition to the standard library. This saves users from having to reimplement the same utility function again and again across projects, possibly making errors in the process.
I wasn't aware of namedtuple's _.replace method. But as far as I can see, the API is not the same as your proposed method either.
I raised it as an example of modifying an immutable type. The exact API of the proposed method is open to discussion.
That, it seems to me, is a pretty insulting thing to say
Not at all. It's appropriate given the tone and content of the post it's addressed to.
to someone who, I would guess, has been using Python for decade(s) longer than you have.
1. On what basis? You don't know who I am. 2. How long they've been using Python is irrelevant. It's also strange to bring up the Python-age of participants after protesting appeal to authority.
Likewise this which you wrote in another post: "Do you see why it's useful to have immutability?"
That's not insulting at all. It's a perfectly valid question to address to a post that seems to be contesting the purpose of immutable types in the first place. ------- Original Message ------- On Friday, March 11th, 2022 at 5:38 PM, Rob Cliffe <rob.cliffe@btinternet.com> wrote:
On Fri, Mar 11, 2022, 6:19 PM wfdc <wfdc@protonmail.com> wrote:
Gosh, I had no idea immutability could be useful! :-) https://openlibra.com/en/book/functional-programming-in-python
Now read what you said earlier:
So it appears the "problem" this is intended to solve is "Python isn't Haskell."
But Haskell exists, and this is a non-problem looking for a solution.
A bizarre incongruence, right? ------- Original Message ------- On Friday, March 11th, 2022 at 6:26 PM, David Mertz, Ph.D. <david.mertz@gmail.com> wrote:
On Fri, Mar 11, 2022 at 06:26:52PM -0500, David Mertz, Ph.D. wrote:
Aren't you the same David Mertz who earlier insisted that wfdc is Doing It Wrong for using tuples when he should be using lists? https://mail.python.org/archives/list/python-ideas@python.org/message/LZAWS3... -- Steve
(To be clear, I'm saying David Mertz's proposal fails the immutability criterion, not Christopher Barker's.) ------- Original Message ------- On Friday, March 11th, 2022 at 4:39 PM, wfdc <wfdc@protonmail.com> wrote: > Don't yell. > > You just effectively re-implemented Christopher Barker's solution (which was also present in the StackOverflow thread), with the downside that it fails the immutability criterion. > > Saying "just be careful not to mutate the original datastructure" isn't a solution. There's a reason we have immutable types: To enforce immutability. Otherwise, why aren't you proposing getting rid of the tuple type entirely? > > ------- Original Message ------- > On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. <david.mertz@gmail.com> wrote: > >> On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas <python-ideas@python.org> wrote: >> >>>> why haven't you used a list >>> 2. I don't want to modify the original sequence. >> >> There's a really easy solution for you that will even be more perfomant. >> >> Use a list and DON'T modify the original! >> >> This is ABSOLUTELY an XY-problem.... which fact was difficult to wrestle out of you. >> >>>>> stuff1 = [a, b, c, d] >>>>> stuff2 = stuff1[:] >>>>> stuff2[2] = e
Yes. To be clear, immutability isn't a use case, it's a particular technique that can be useful for solving some problems. This is probably a clear enough example of the XY-problem as to be worth adding to the Wikipedia article on that topic. We sometimes see other similar proposals to e.g. "solve" the "problem" that Python isn't statically typed. That is, folks who want Python to be some different language. On Fri, Mar 11, 2022, 4:42 PM wfdc <wfdc@protonmail.com> wrote: > (To be clear, I'm saying David Mertz's proposal fails the immutability > criterion, not Christopher Barker's.) > > ------- Original Message ------- > On Friday, March 11th, 2022 at 4:39 PM, wfdc <wfdc@protonmail.com> wrote: > > Don't yell. > > You just effectively re-implemented Christopher Barker's solution (which > was also present in the StackOverflow thread), with the downside that it > fails the immutability criterion. > > Saying "just be careful not to mutate the original datastructure" isn't a > solution. There's a reason we have immutable types: To *enforce* > immutability. Otherwise, why aren't you proposing getting rid of the tuple > type entirely? > > ------- Original Message ------- > On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. < > david.mertz@gmail.com> wrote: > > On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas < > python-ideas@python.org> wrote: > >> > why haven't you used a list >> 2. I don't want to modify the original sequence. >> > > There's a really easy solution for you that will even be more perfomant. > > Use a list and DON'T modify the original! > > This is ABSOLUTELY an XY-problem.... which fact was difficult to wrestle > out of you. > > >>> stuff1 = [a, b, c, d] > >>> stuff2 = stuff1[:] > >>> stuff2[2] = e > > > > >
So do you propose getting rid of the tuple type entirely or not? Do you see why it's useful to have immutability? ------- Original Message ------- On Friday, March 11th, 2022 at 4:47 PM, David Mertz, Ph.D. <david.mertz@gmail.com> wrote: > Yes. To be clear, immutability isn't a use case, it's a particular technique that can be useful for solving some problems. > > This is probably a clear enough example of the XY-problem as to be worth adding to the Wikipedia article on that topic. > > We sometimes see other similar proposals to e.g. "solve" the "problem" that Python isn't statically typed. That is, folks who want Python to be some different language. > > On Fri, Mar 11, 2022, 4:42 PM wfdc <wfdc@protonmail.com> wrote: > >> (To be clear, I'm saying David Mertz's proposal fails the immutability criterion, not Christopher Barker's.) >> >> ------- Original Message ------- >> On Friday, March 11th, 2022 at 4:39 PM, wfdc <wfdc@protonmail.com> wrote: >> >>> Don't yell. >>> >>> You just effectively re-implemented Christopher Barker's solution (which was also present in the StackOverflow thread), with the downside that it fails the immutability criterion. >>> >>> Saying "just be careful not to mutate the original datastructure" isn't a solution. There's a reason we have immutable types: To enforce immutability. Otherwise, why aren't you proposing getting rid of the tuple type entirely? >>> >>> ------- Original Message ------- >>> On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. <david.mertz@gmail.com> wrote: >>> >>>> On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas <python-ideas@python.org> wrote: >>>> >>>>>> why haven't you used a list >>>>> 2. I don't want to modify the original sequence. >>>> >>>> There's a really easy solution for you that will even be more perfomant. >>>> >>>> Use a list and DON'T modify the original! >>>> >>>> This is ABSOLUTELY an XY-problem.... which fact was difficult to wrestle out of you. >>>> >>>>>>> stuff1 = [a, b, c, d] >>>>>>> stuff2 = stuff1[:] >>>>>>> stuff2[2] = e
On Sat, 12 Mar 2022 at 08:53, wfdc via Python-ideas <python-ideas@python.org> wrote:
So do you propose getting rid of the tuple type entirely or not?
Do you see why it's useful to have immutability?
Immutability is extremely useful. I use tuples VERY frequently. But I don't then need to replace one element in them. ChrisA
You may not, but others do. 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 and 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 ------- Original Message ------- On Monday, March 14th, 2022 at 8:31 AM, Chris Angelico <rosuav@gmail.com> wrote:
Wow! Does anyone else see the irony in the fact that just a couple days ago, Chris A lamented that Python-ideas seemed to Immediately reject any new idea out of hand? And yes, Chris, you have joined in the piling on in this case. I didn’t think it was that bad, but this thread has been pretty painful. I’m pretty surprised that folks seem to be denying that this proposal has any use at all. Is this a major need? Obviously not, As for “not every one line function..” I demonstrated quite clearly that its not a one liner, it’s not obvious, and as Marco pointed out, it literally has to be a built in to get top performance. Is the SC likely to think it’s worth adding a new method to a core built in for? Probably not. But not rising to the very high standard that changes to core Python need is not the same as a pointless or bad idea. Thanks Paul for laying out what would have to be done honestly. To rest of you Debbie Downers -. Really? -CHB On Fri, Mar 11, 2022 at 1:51 PM wfdc via Python-ideas < python-ideas@python.org> wrote: > So do you propose getting rid of the tuple type entirely or not? > > Do you see why it's useful to have immutability? > > ------- Original Message ------- > > On Friday, March 11th, 2022 at 4:47 PM, David Mertz, Ph.D. < > david.mertz@gmail.com> wrote: > > Yes. To be clear, immutability isn't a use case, it's a particular > technique that can be useful for solving some problems. > > This is probably a clear enough example of the XY-problem as to be worth > adding to the Wikipedia article on that topic. > > We sometimes see other similar proposals to e.g. "solve" the "problem" > that Python isn't statically typed. That is, folks who want Python to be > some different language. > > > On Fri, Mar 11, 2022, 4:42 PM wfdc <wfdc@protonmail.com> wrote: > >> (To be clear, I'm saying David Mertz's proposal fails the immutability >> criterion, not Christopher Barker's.) >> >> ------- Original Message ------- >> On Friday, March 11th, 2022 at 4:39 PM, wfdc <wfdc@protonmail.com> wrote: >> >> Don't yell. >> >> You just effectively re-implemented Christopher Barker's solution (which >> was also present in the StackOverflow thread), with the downside that it >> fails the immutability criterion. >> >> Saying "just be careful not to mutate the original datastructure" isn't a >> solution. There's a reason we have immutable types: To *enforce* >> immutability. Otherwise, why aren't you proposing getting rid of the tuple >> type entirely? >> >> ------- Original Message ------- >> On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. < >> david.mertz@gmail.com> wrote: >> >> On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas < >> python-ideas@python.org> wrote: >> >>> > why haven't you used a list >>> 2. I don't want to modify the original sequence. >>> >> >> There's a really easy solution for you that will even be more perfomant. >> >> Use a list and DON'T modify the original! >> >> This is ABSOLUTELY an XY-problem.... which fact was difficult to wrestle >> out of you. >> >> >>> stuff1 = [a, b, c, d] >> >>> stuff2 = stuff1[:] >> >>> stuff2[2] = e >> >> >> >> >> > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-leave@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/K3CWHSBWAA5PANVV44CVQPDVEAIYAJ7N/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
Just to add, the following Sourcegraph queries provide good evidence of widespread use of this functionality: 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 ------- Original Message ------- On Saturday, March 12th, 2022 at 1:41 AM, Christopher Barker <pythonchb@gmail.com> wrote:
On Mon, 14 Mar 2022 at 23:54, Christopher Barker <pythonchb@gmail.com> wrote:
There definitely is a problem when my post, which was asking for more details, can be seen as merely piling on the criticism. It indicates that there is so much criticism that everything starts to look like it. In this particular thread, the OP certainly isn't helping to solve the issue, as there has STILL been no answer to the questions of "why not use namedtuple" and "why not use a dataclass", and no sample code provided. But yes, when the dogpile gets so big that every post looks like more dogpiling, there is a bit of a problem. So no, I don't see it as ironic. The only difference is that, here, I wouldn't lament the thread just dying. ChrisA
there has STILL been no answer to the questions of "why not use namedtuple" and "why not use a dataclass"
Christopher addressed that a long time ago.
no sample code provided
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 ------- Original Message ------- On Monday, March 14th, 2022 at 8:56 AM, Chris Angelico <rosuav@gmail.com> wrote:
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
On Tue, 15 Mar 2022 at 05:37, Christopher Barker <pythonchb@gmail.com> wrote:
My apologies. The thread has gotten VERY noisy, and I did miss the fact that you'd said this; partly because the OP has only had arguments like "namedtuples aren't sequences", which are not what I'd call compelling. I still stand by the sentiment that sample code from the OP is more important than someone else's explanation of why namedtuple might not be suitable, but perhaps the OP sees it as an answered question. I've been keeping the tone as positive as possible, but honestly, I don't think this thread has much hope of being productive at this point, and if you hadn't called me out specifically, I would not have responded. ChrisA
the OP has only had arguments like "namedtuples aren't sequences", which are not what I'd call compelling.
Why don't you answer the question I asked you? ------- Original Message ------- On Monday, March 14th, 2022 at 4:12 PM, Chris Angelico <rosuav@gmail.com> wrote:
Travel Portal Development We have a devoted group of engineers bringing unparalleled experience and information to the table for the clients, a one of a kind travel gateway that will certainly speed up the brand or business. https://www.flightapis.com/travel-portal-development
Game theorist here. wfdc via Python-ideas writes:
Do you see why it's useful to have immutability?
Sure, it's potentially hashable. But I can't recall ever finding that useful in working with matrix games (loosely speaking, I mean games with a finite set of players, each with a finite strategy space). I've used (subclasses of) tuple for strategy profiles, but I always wanted more additional attributes than just 'replace' (thus subclasses), and I call it "deviate" (usually) or "disturbance" (when computing perfect or proper equilibria; of course those implicate the mixed extension, which complicates thing, and also they involve changing all the non-interior strategies simultaneously). Really curious to hear enough about your use case to understand why adding this method to tuple is so much preferable to using a list (which is what I do when calculating best replies in an abstract matrix game, eg toy examples for introductory classes) or some class based on dict, list, or tuple (when the game is a model of some social phenomenon and I want to access various summaries of performance "at" a profile).
You are, and you have every right to. I want to talk about immutable sequences, and that's fine, too. The point is that str and tuples are both immutable sequences, and both "replace at index" and "replace value" make sense for all sequences. Of course mutable sequences already have the usual indexing and slicing APIs for replacement, so this would be immutables only. BTW, bytes.replace has the same signature as str.replace. It's true that namedtuple has a replace method with a different signature, but that signature relates to namedtuple as a (general) *mapping*, not as a *sequence* (which, although it's a special case of mapping, is sufficiently important to have two builtin implementations).
True. I wouldn't expect the replace method on ints to be the same as the replace method on tuples. I would expect the replace method on immutable sequences to be consistent across subtypes. I don't yet see a reason why "replace value" wouldn't be at least as useful "replace at index". And in fact "replace value" is plausible for list, as well, with that signature. Based on the precedent set by other immutable sequences, I'm firmly -1 on the name "replace" for "replace at". I'm -1 on adding it to tuple with any name, but I could be convinced otherwise based on systematic evidence that it's broadly useful, such as a survey of the stdlib. Steve
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 and 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 ------- Original Message ------- On Sunday, March 13th, 2022 at 1:55 AM, Stephen J. Turnbull <stephenjturnbull@gmail.com> wrote:
Hi, You are clearly not making progress, and this list is no longer useful to you for this idea -- you know what you want, it's easy enough to implement, and you don't need our advice for that I assume. I suggest you give up on this list, write the code, make sure it's well-documented, and submit a merge request. If you don't get a timely response (ie, after a decent interval for the relevant folks to pick up the merge request) ping python-dev directly for a decision. If you're worried about coding style or exactly how the submission process works, core-mentorship@python.org will give you help on that with a minimum of backseat driving. wfdc via Python-ideas writes:
You're going to have to work harder than that to convince me. It's not clear how many of those examples are unique, and most are concise and idiomatic. Good luck! Steve
You're going to have to work harder than that to convince me. It's not clear how many of those examples are unique, and most are concise and idiomatic.
Ridiculous goalpost-moving. I literally just gave you 1000+ examples of this functionality being used, which is what you asked for, including by several important repositories and organizations: - pytorch - pandas - apache - numpy - jax - sympy - cupy - tensorflow - pyqtgraph - aws - dask - deepmind - h5py - cloudflare - facebook research and so on. At this point, it seems like you're just trying to save face. ------- Original Message ------- On Monday, March 14th, 2022 at 9:47 AM, Stephen J. Turnbull <stephenjturnbull@gmail.com> wrote:
On Mon, Mar 14, 2022 at 04:57:09PM +0000, wfdc via Python-ideas wrote:
100 repetitions of the same dozen or so examples is no stronger evidence than just listing a dozen unique examples. wfdc, whether you like it or not, Python is not yours to change as you see fit. (Being open source, you are welcome to fork it and do whatever you want with it.) You have to not just convince others that your proposal is useful, but that it is is **useful enough** to build it into the language. It is true that much of this thread has been dominated by some extremely negative, condescending replies. But you are not helping by biting the hands of those trying to help you. You have been told the processes that you have to follow to get this change accepted into Python. Snarling and biting at us is not going to change that. I don't know how things are like in your workplace, assuming you are a professional coder, but you cannot intimidate us by snarling. You will just get muted and your emails deleted. So chill out. Enhancement requests are not Default Accept. You can try putting an enhancement request on the bug tracker, but almost certainly you will be told to propose it here to see if there is consensus that it is useful enough. You can submit a PR on the repo, but likewise. You can ask on Python-Dev, but you will almost certainly be told you need to write a PEP, and to have that PEP even accepted for consideration you need to have at least one core developer volunteer to sponsor it. You could discuss it on Discuss, where at least you are likely to get feedback from a different set of people, but the eventual answer will be the same: this almost surely will need a PEP. Yes, this is all a damn nuisance, but it is what it is and you have to work with the system we have, not the system you want. And if you think this is problematic, you should try proposing a change to the Java or C languages. -- Steve
Steven D'Aprano writes:
That's a good description of the various paths, but I don't think the bar here is as high as a PEP. I don't recall there being a PEP for zip(..., strict=). This is somewhat more invasive than that, but I really don't see a need for a PEP. The motivation is obvious, the implementation is trivial unless you want to catch edge cases like replacing an index that's out of bounds (note ()[:0] + ()[1:] => ()), but that's the only such I can think of, and that's close to trivial. The only justification I can see for a PEP would be a curated list of usages and/or description of a compelling use case. The former *would* be a PITA that wfdc is manifestly unwilling to perform. The latter is nonexistent, it's a three-line function, and that's assuming you go for overkill with argument-checking. Saying that it's been discussed on Python Ideas, and now it's ready for review, should be enough to foreclose bringing it back here. I think the likely response to a PR is summary closure, but that's the best bet. There's nothing to be learned by continuing this thread, that's for sure.
Yes, this is all a damn nuisance,
Not compared to the free-fire zones I've seen in some projects. ;-) Steve
On Thu, 17 Mar 2022 at 01:09, Stephen J. Turnbull <stephenjturnbull@gmail.com> wrote:
participants (8)
-
Chris Angelico -
Christopher Barker -
David Mertz, Ph.D. -
flightapisseo＠gmail.com -
Rob Cliffe -
Stephen J. Turnbull -
Steven D'Aprano -
wfdc