[Python-ideas] Re: Add a replace method to tuples
On Mon, Mar 14, 2022, 7:52 PM Steven D'Aprano > I got "No results matched your query" on the second URL, at which point I > didn't bother with the first. > Hmm... while I don't support the proposal, I saw results at both links. Those links were the first good faith comments I saw from OP. A pretty large number of prominent projects use either: foo = bar[:n] + newval + bar[n+1:] Or: newfoo = list(foo) newfoo[n] = newval foo = tuple(newfoo) Somewhere in their codebases. I find that mild evidence in favor of the idea. But the pattern seems to be "occasionally in large-ish projects." On the other hand, looking through those examples in a cursory manner made me think about 75% of the time "why are they doing this silly approach?" and 25% "this is easy enough as is." None of them made me think "I wish I had a method/function." ___ 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/2FZ6N2W4FUK3IA4OICA2UZASQTZ6FPIO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On 2022-03-09 19:42, wfdc via Python-ideas wrote: Add a "replace" method to tuples that returnsa new tuple with the element at a given index replaced with a given value. Hmm, no one appears to have mentioned DateTime.replace(). Did I miss it? https://docs.python.org/3/library/datetime.html#datetime.date.replace I think it demonstrates that this is a valid and useful pattern. Agree that I don't often have a need, but am glad it exists. -Mike ___ 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/AV6VWQPHIJ4JELLHXBPFDRSWZEZ2XGY5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On Tue, Mar 15, 2022 at 10:51:21AM +1100, Steven D'Aprano wrote: > I got "No results matched your query" on the second URL, at which point > I didn't bother with the first. I tried again, with both URLs, and got plenty of hits this time. Perhaps I had a copy-paste error with the URLs, or a transient error on the website. Those results are promising, but there is a lot of obviously duplicated code there. That's why somebody needs to curate it. -- 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/BAOHE4G52U3NLU46ELNBG4S5PGSZLNFC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> I got "No results matched your query" on the second URL, at which point I > didn't bother with the first. Check again in case it's an error. 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=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=regexp I get 500+ results for each query, including code from several prominent repositories and organizations, such as: - pytorch - pandas - apache - numpy - jax - sympy - cupy - tensorflow - pyqtgraph - aws - dask - deepmind - h5py - cloudflare - facebook research and so on. > My perspective is that replacement of an item in a tuple is so simple that it > isn't even worth a utility function unless it is generalised. I don't oppose the latter. > Just build a new tuple using slicing and concatenation expressions. Not every > expression is worth an actual named function. I feel that this proposal is > too small to bother with a function, let alone adding it to the tuple as a > builtin method. See Christopher's comments on performance as a builtin. --- Original Message --- On Monday, March 14th, 2022 at 7:51 PM, Steven D'Aprano wrote: > On Mon, Mar 14, 2022 at 04:38:48PM +, wfdc wrote: > > > > 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. > > > > Like I said, this puts it in the top 3031 / 1908740 = 0.00159 = 0.159% > > > > of Python questions by vote count. > > > > That's not "a low number of votes" no matter how you try to spin it. > > It doesn't matter whether it is the top 0.159% or the top 0.0001%, > > 160 votes or so is an objectively low number compared to the top ranking > > questions, with almost 100 times as many votes. > > Not that it matters. Even if the question had a trillion votes, that > > alone is not sufficient to justify the proposal. > > > > Popularity on StackOverflow is just a vague indication of > > > > > > popularity, not a sign of need or usefulness. > > > > Then see > > > > https://sourcegraph.com/search?q=context:global+lang:python+\[\s*:\s*(i|j|k|ind|index)\s*\]\s*\%2B\s*\(.%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%5Cs1%5Cs:%5Cs*%5C%5D=regexp > > > > https://sourcegraph.com/search?q=context:global+lang:python+%3D\slist%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=regexp > > > > for plenty more examples. > > I got "No results matched your query" on the second URL, at which point > > I didn't bother with the first. > > Thank you for providing some search terms, but you misunderstand the > > process of proposing new functionality to the builtins and stdlib. The > > onus is not on us to do the work, but for those making the proposal. > > If we ask for examples, we expect you to do the work of curating some > > good examples, not just to dump a regex in our laps and tell us to > > search for them ourselves. > > The bottom line here is that we don't have to justify why the proposal > > isn't accepted. New feature requests are not Default Accept. All we need > > to do is nothing at all and the proposal doesn't go ahead. > > At this point, I don't think this discussion on Python-Ideas is going > > anywhere, which is a shame because I actually do like it. > > Those who are opposed to changes (whether for good reasons or bad) are > > dominating the discussion. You aren't going to change their mind. Those > > who are neutral or in favour have had their voices drowned out. We've > > already had the mailing list put into Emergency Moderation once, > > presumably because tempers are getting frayed. > > I think that your strategies here could include: > > (1) Give this up as a lost cause. > > (2) Ignore the negative feedback here and raise it as an enhancement > > request on the bug tracker, or a PR on the repo. > > You will probably have it rejected and be told to discuss it on > > Python-Ideas, but you might be lucky and get the interest of a core > > developer who loves this proposal and accepts it. (But probably not.) > > (3) Look for some fresh feedback, hopefully (from your perspective) less > > conservative and negative. Try the "Ideas" topic on Discus. > > Take into account the feedback you have already received. We've told you > > the sorts of things that the core devs and Steering Council will be > > looking for. If you're not willing to provide that, you'll get the same > > response. > > Python is a mature language, and the core developers and
[Python-ideas] Re: Add a replace method to tuples
On Mon, Mar 14, 2022 at 11:53:37AM -0700, Christopher Barker wrote: > I don't think it should be added to mutable types -- there are already ways > to do that, and there are any number of "make a new one with some change" > methods that mutables don't have. How do we make a new list with a change other than the same slice and concatenation we use with tuples? alist[:i] + [value] + alist[i+1:] I mean as an expression, of course we can split it over two statements: newlist = alist[:] newlist[i] = value which is fine, but it does lose the expressiveness of an expression :-) -- 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/XY467Q2HACUJRR647BXDLBD6AFWOECZK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On Mon, Mar 14, 2022 at 04:38:48PM +, wfdc wrote: > > 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. > > Like I said, this puts it in the top 3031 / 1908740 = 0.00159 = 0.159% > of Python questions by vote count. > > That's not "a low number of votes" no matter how you try to spin it. It doesn't matter whether it is the top 0.159% or the top 0.0001%, 160 votes or so is an objectively low number compared to the top ranking questions, with almost 100 times as many votes. Not that it matters. Even if the question had a trillion votes, that alone is not sufficient to justify the proposal. > > Popularity on StackOverflow is just a vague indication of > > popularity, not a sign of need or usefulness. > > Then 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=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=regexp > > for plenty more examples. I got "No results matched your query" on the second URL, at which point I didn't bother with the first. Thank you for providing some search terms, but you misunderstand the process of proposing new functionality to the builtins and stdlib. The onus is not on *us* to do the work, but for those making the proposal. If we ask for examples, we expect you to do the work of curating some good examples, not just to dump a regex in our laps and tell us to search for them ourselves. The bottom line here is that we don't have to justify why the proposal isn't accepted. New feature requests are not Default Accept. All we need to do is *nothing at all* and the proposal doesn't go ahead. At this point, I don't think this discussion on Python-Ideas is going anywhere, which is a shame because I actually do like it. Those who are opposed to changes (whether for good reasons or bad) are dominating the discussion. You aren't going to change their mind. Those who are neutral or in favour have had their voices drowned out. We've already had the mailing list put into Emergency Moderation once, presumably because tempers are getting frayed. I think that your strategies here could include: (1) Give this up as a lost cause. (2) Ignore the negative feedback here and raise it as an enhancement request on the bug tracker, or a PR on the repo. You will *probably* have it rejected and be told to discuss it on Python-Ideas, but you might be lucky and get the interest of a core developer who loves this proposal and accepts it. (But probably not.) (3) Look for some fresh feedback, hopefully (from your perspective) less conservative and negative. Try the "Ideas" topic on Discus. Take into account the feedback you have already received. We've told you the sorts of things that the core devs and Steering Council will be looking for. If you're not willing to provide that, you'll get the same response. Python is a mature language, and the core developers and Steering Council are conservative when it comes to adding marginally useful features that aren't obvious Big Wins, and this is not a Big Win, it is at best a Small Win. This post from one of the core devs may help you understand the culture here: https://www.curiousefficiency.org/posts/2011/04/musings-on-culture-of-python-dev.html My advice to you is that if your time and care factor is low, save your energy for battles you *really* care about. We all want what is best for Python, we may just disagree on what the balance of pros and cons are. If your care factor is high, and you want to continue gathering support for the proposal with the intention of writing a PEP, then listen to those of us who have written successful PEPs in the past. > See also the "batteries included" point that was made ages ago. (If > users find themselves re-implementing the same utility function over > and over again across different projects, it's a good sign that such a > function should be part of the standard library.) It is a sign, but how strong a sign is open for debate. My perspective is that replacement of an item in a tuple is *so simple* that it isn't even worth a utility function unless it is generalised. Just build a new tuple using slicing and concatenation expressions. Not every expression is worth an actual named function. I feel that this proposal is *too small* to bother with a function, let alone adding it to the tuple as a builtin method. But generalising it to all sequences, not just tuples, that interests me more. I've used this on strings and lists, probably more often
[Python-ideas] Re: Add a replace method to tuples
Again, you neglected to answer the question: > what are the field names supposed to be if the datastructure is being treated > as a sequence, of possibly arbitrary length? > Since a namedtuple is supposed to be both a sequence and a record, the names > are part of the record interface, and the sequence is still part of that. The point is that I *don't* want to treat it as a record, and I have no reason to. That's precisely the point I'm making! > the field names don't have to be valid identifiers Yes, they do. > if it's a sequence of arbitrary length, then why is it a tuple at all? Why wouldn't it be? A tuple is a sequence. And a sequence can be of arbitrary length. > You assume that it has to be a tuple but not a namedtuple, but a namedtuple > IS a tuple. See my first question. > Do you see why we've been asking you to SHOW YOUR CODE? I already provided *plenty* of examples through the Sourcegraph queries. There's no reason for me to give you my specific code, nor does it help this discussion in any way, since I already gave you plenty of examples. --- Original Message --- On Monday, March 14th, 2022 at 7:04 PM, Chris Angelico wrote: > On Tue, 15 Mar 2022 at 10:02, wfdc via Python-ideas > > python-ideas@python.org wrote: > > > See my previous response to Chris: > > > > > What are the named fields supposed to be if the datastructure is being > > > treated as a sequence? Indices again? Then what's the point of using > > > namedtuple rather than tuple in the first place? > > > > > And, by the way, field names must be valid identifiers. > > > > > So again, what are the field names supposed to be if the datastructure is > > > being treated as a sequence, of possibly arbitrary length? > > It's very hard to answer a question that is fundamentally based on a > > misunderstanding of namedtuples. Since a namedtuple is supposed to > > be both a sequence and a record, the names are part of the record > > interface, and the sequence is still part of that. Also, the field > > names don't have to be valid identifiers (although they usually will). > > But if it's a sequence of arbitrary length, then why is it a tuple at > > all? You assume that it has to be a tuple but not a namedtuple, but a > > namedtuple IS a tuple. > > Do you see why we've been asking you to SHOW YOUR CODE? > > I am done. I'm not going to further respond in this thread until there > > is some actual code to discuss. > > ChrisA > > ___ > > 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/SAHYE2XVOAFBJ7UO5ZTECH4GVTEA5XKC/ > > 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/MY2EWIXDDU7CCO3ZLUCG4XFK3FNFO653/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On Tue, 15 Mar 2022 at 10:02, wfdc via Python-ideas wrote: > > See my previous response to Chris: > > > What are the named fields supposed to be if the datastructure is being > > treated as a sequence? Indices again? Then what's the point of using > > namedtuple rather than tuple in the first place? > > > And, by the way, field names must be valid identifiers. > > > So again, what are the field names supposed to be if the datastructure is > > being treated as a sequence, of possibly arbitrary length? > It's very hard to answer a question that is fundamentally based on a misunderstanding of namedtuples. Since a namedtuple *is* supposed to be both a sequence and a record, the names are part of the record interface, and the sequence is still part of that. Also, the field names don't have to be valid identifiers (although they usually will). But if it's a sequence of arbitrary length, then why is it a tuple at all? You assume that it has to be a tuple but not a namedtuple, but a namedtuple IS a tuple. Do you see why we've been asking you to SHOW YOUR CODE? I am done. I'm not going to further respond in this thread until there is some actual code to discuss. ChrisA ___ 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/SAHYE2XVOAFBJ7UO5ZTECH4GVTEA5XKC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> 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 wrote: > On Tue, 15 Mar 2022 at 05:37, Christopher Barker python...@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 > > > > 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. > > 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 > > ___ > > 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/HBNI5IEQQ5X4EGKNG5ZSAFBEVGGK4QVQ/ > > 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/NUO64EVTMDG7CFDRCLBGVY5QMKA2ER67/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
See my previous response to Chris: > What are the named fields supposed to be if the datastructure is being > treated as a sequence? Indices again? Then what's the point of using > namedtuple rather than tuple in the first place? > And, by the way, field names must be valid identifiers. > So again, what are the field names supposed to be if the datastructure is > being treated as a sequence, of possibly arbitrary length? --- Original Message --- On Monday, March 14th, 2022 at 6:19 PM, Greg Ewing wrote: > On 15/03/22 6:14 am, wfdc via Python-ideas wrote: > > > The whole point is that namedtuples let you use named fields rather than > > indices. That's the point. That's the purpose. > > I would say the point of namedtuple is to let you use either field > > names or indices, whichever makes the most sense for what you're > > doing at the time. Otherwise why not just use a regular class? > > -- > > Greg > > ___ > > 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/6Z3SGL4AJEBS2W4URZ5D4UH4KKPC6IAX/ > > 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/BDSIDWEQO3KFWQBN2EFSSWMHOJJS6OGZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On Mon, 14 Mar 2022 at 22:21, Greg Ewing wrote: > > On 15/03/22 6:14 am, wfdc via Python-ideas wrote: > > The whole *point* is that namedtuples let you use *named fields* rather > > than indices. That's the point. That's the purpose. > > I would say the point of namedtuple is to let you use either field > names or indices, whichever makes the most sense for what you're > doing at the time. Otherwise why not just use a regular class? As I understood it, one motivation for the introduction of namedtuple was that where you had an API that returned a tuple you could change that to return a namedtuple without breaking backwards compatibility. Then older code expecting a tuple could still use tuple-ish idioms like unpacking, slicing or indexing but newer code could use names to access the elements. -- Oscar ___ 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/5TEZKOONYRJUHJVLD55XRBEBYWZEZARV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On 15/03/22 6:14 am, wfdc via Python-ideas wrote: The whole *point* is that namedtuples let you use *named fields* rather than indices. That's the point. That's the purpose. I would say the point of namedtuple is to let you use either field names or indices, whichever makes the most sense for what you're doing at the time. Otherwise why not just use a regular class? -- Greg ___ 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/6Z3SGL4AJEBS2W4URZ5D4UH4KKPC6IAX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On Tue, 15 Mar 2022 at 05:37, Christopher Barker 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 > > 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. 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 ___ 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/HBNI5IEQQ5X4EGKNG5ZSAFBEVGGK4QVQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On Mon, Mar 14, 2022 at 11:16 AM wfdc via Python-ideas < python-ideas@python.org> wrote: > jax is another example that uses the name 'set' for this functionality: > > https://jax.readthedocs.io/en/latest/jax.numpy.html set() strikes me as a better name for a mutating operation. Apparently Jax arrays are immutable, but from the Jax docs: "For example, instead of in-place array updates (x[i] = y), JAX provides an alternative pure indexed update function x.at[i].set(y)" I'd need to read more before I understood that that means (what does x.at[] return? But this does look pretty different than the proposal. Personally, I think the symmetry between this and datatime.replace and namedtuple._replace is actually a good thing, even though the API is a little different. On second thought, perhaps it wouldn't be a bad idea to extend this > proposal to built-in sequence types in general (list, str, tuple, and > bytes). > I don't think it should be added to mutable types -- there are already ways to do that, and there are any number of "make a new one with some change" methods that mutables don't have. Essentially, the API of mutable and immutable types is already different. Are you proposing that this be added to an ABC? That would be a heavier lift, and now that I think about it, there is no ABC for immutable sequences -- they are simply sequences -- which don't have any mutating methods. If you are proposing that it be added to a handful of built-in types -- I don't think that should be done for the sake of symmetry, but only if it's useful for that type. -- do we often want to replace the nth character in a string? or the nth byte in a bytes object? Maybe? I don't think I"ve ever needed to do that. > If extended beyond tuples, we would have to address the name collision > with the existing 'replace' methods of str and bytes. In that case, > something like 'set' or 'update' might work. (I prefer the former for its > conciseness.) > yup -- so I suppose another name would be helpful for future extending. (dict has update() -- would that add confusion?) -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/YH6HN24IGK4I3C7D2L2ZIX7CDIOVERLU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> 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/
[Python-ideas] Re: Add a replace method to tuples
jax is another example that uses the name 'set' for this functionality: https://jax.readthedocs.io/en/latest/jax.numpy.html On second thought, perhaps it wouldn't be a bad idea to extend this proposal to built-in sequence types in general (list, str, tuple, and bytes). Examples of this functionality being used on those other types: 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.*%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=regexp If extended beyond tuples, we would have to address the name collision with the existing 'replace' methods of str and bytes. In that case, something like 'set' or 'update' might work. (I prefer the former for its conciseness.) --- Original Message --- On Monday, March 14th, 2022 at 12:47 PM, wfdc wrote: > > wfdc (should we call you something which is not a random-looking string of > > consonants?) > > wfdc is fine. > > > it might help if you could give examples of this functionality from other > > languages or classes. What do they call the method? > > https://clojuredocs.org/clojure.core/assoc > > https://immutable-js.com/docs/v4.0.0/set()/ > > http://swannodette.github.io/mori/#assoc > > https://hackage.haskell.org/package/lens-5.1/docs/Control-Lens-Operators.html#v:.-126- > > https://hackage.haskell.org/package/containers-0.6.5.1/docs/Data-Sequence.html#update > > What about 'update' or 'set'? > > > what if index assignment was an expression? [...] Now that I have seen this > > syntax, I want it!!! > > Interesting idea. Perhaps we can discuss it further. > > --- Original Message --- > > On Monday, March 14th, 2022 at 8:38 AM, Steven D'Aprano st...@pearwood.info > wrote: > > > On Fri, Mar 11, 2022 at 01:38:57AM +, Rob Cliffe via Python-ideas wrote: > > > > > This could cause confusion because str.replace() has a completely > > > > > > different API. > > > > The old "painter.draw()" versus "gun_slinger.draw()" problem. > > > > It does exist, but it's not generally a major problem. > > > > > And indeed if a replace method were added to tuples, a fair case could > > > > > > be made for it having the same API, viz. > > > > > > replace(old, new, count=-1) > > > > A reasonable suggestion. Does replace change items according to their > > > > position, or their value? > > > > Perhaps a better name would help. > > > > wfdc (should we call you something which is not a random-looking string > > > > of consonants?) it might help if you could give examples of this > > > > functionality from other languages or classes. What do they call the > > > > method? > > > > It would be nice to have a better API for this function. I have used it > > > > many times, for strings, lists and tuples, it is really a generate > > > > sequence operation: > > > > * make a copy of the sequence, replacing the item at position p with a > > > > new value; > > > > We can do it with type-specific expressions: > > > > seq[:p] + [value] + seq[p+1:] > > > > seq[:p] + (value,) + seq[p+1:] > > > > string[:p] + "c" + string[p+1:] > > > > but there is no good, type-agnostic way to easily do it. > > > > Wacky thought: what if index assignment was an expression? > > > > function(arg, seq[p]=value, another_arg) > > > > would pass a copy of seq with the item at p replaced by value. That > > > > would work with slices as well: > > > > seq[a:b] = values > > > > Now that I have seen this syntax, I want it!!! > > > > (It is not clear to me if this would be compatible to the existing > > > > `setitem API.) > > > > > Whereas your suggestion can be written as a simple 1-liner, as you > > > > > > demonstrate. So there is no strong need for a new method for it. > > > > Sure, not all one-liners need to be built-in. But some do. > > > > -- > > > > 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/HKYHO35W5M3LKUGUZ6MRYVVEIKUQ5XHC/ > > > > 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/32V2TGUAVGJZQJ2NOYYJHNYYUTXXR545/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
And, by the way, field names must be valid identifiers. So again, what are the field names supposed to be if the datastructure is being treated as a sequence, of possibly arbitrary length? --- Original Message --- On Monday, March 14th, 2022 at 1:07 PM, Chris Angelico wrote: > On Tue, 15 Mar 2022 at 04:02, wfdc w...@protonmail.com wrote: > > > > A namedtuple IS a sequence. It is a tuple. They are deliberately designed > > > to be drop-in replacements for tuples. > > > > I meant that they're not meant to be addressed as sequences. That's the > > whole point of namedtuple: to avoid doing that. > > The whole point is that they are both sequences and structures. > > https://docs.python.org/3/library/collections.html#collections.namedtuple > > ChrisA > > ___ > > 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/5QBJGA4UB3JJ34IULQSFHTBEZGBEFV7U/ > > 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/6V7WSM76RTHKOPHKVNHKROSJ63EKXRW3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
The whole *point* is that namedtuples let you use *named fields* rather than indices. That's the point. That's the purpose. What are the named fields supposed to be if the datastructure is being treated as a sequence? Indices again? Then what's the point of using namedtuple rather than tuple in the first place? Again, I direct you to Christopher's comment on the matter. --- Original Message --- On Monday, March 14th, 2022 at 1:07 PM, Chris Angelico wrote: > On Tue, 15 Mar 2022 at 04:02, wfdc w...@protonmail.com wrote: > > > > A namedtuple IS a sequence. It is a tuple. They are deliberately designed > > > to be drop-in replacements for tuples. > > > > I meant that they're not meant to be addressed as sequences. That's the > > whole point of namedtuple: to avoid doing that. > > The whole point is that they are both sequences and structures. > > https://docs.python.org/3/library/collections.html#collections.namedtuple > > ChrisA > > ___ > > 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/5QBJGA4UB3JJ34IULQSFHTBEZGBEFV7U/ > > 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/CB5P5W7I2IID2AUMF72F3HKSD3V52UGA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On Tue, 15 Mar 2022 at 04:02, wfdc wrote: > > > A namedtuple IS a sequence. It is a tuple. They are deliberately designed > > to be drop-in replacements for tuples. > > I meant that they're not meant to be addressed as sequences. That's the whole > point of namedtuple: to avoid doing that. > The whole point is that they are both sequences and structures. https://docs.python.org/3/library/collections.html#collections.namedtuple ChrisA ___ 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/5QBJGA4UB3JJ34IULQSFHTBEZGBEFV7U/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> A namedtuple IS a sequence. It is a tuple. They are deliberately designed to > be drop-in replacements for tuples. I meant that they're not meant to be addressed as sequences. That's the whole point of namedtuple: to avoid doing that. And the first point still applies. --- Original Message --- On Monday, March 14th, 2022 at 12:19 PM, Chris Angelico wrote: > On Tue, 15 Mar 2022 at 03:16, wfdc w...@protonmail.com wrote: > > > > Yes, and dataclasses and namedtuples support this concept very nicely. > > > You still haven't shown why neither works. > > > > 1. They're less efficient, as Christopher pointed out long ago. > > > > 2. They're not sequences, so conceptually the wrong tool for the job. > > A namedtuple IS a sequence. It is a tuple. They are deliberately > > designed to be drop-in replacements for tuples. > > ChrisA > > ___ > > 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/OYMJH6445PZ2P4LE5SGLH3QKXV2FHNH5/ > > 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/HPTTY7SIR6C7MFQID7WE65KDTXMFCTFU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> 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 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-mentors...@python.org will give you help on that with a > > minimum of backseat driving. > > wfdc via Python-ideas writes: > > > https://sourcegraph.com/search?q=context:global+lang:python+\[\s*:\s*(i|j|k|ind|index)\s*\]\s*\%2B\s*\(.%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%5Cs1%5Cs:%5Cs*%5C%5D=regexp > > 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 ___ 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/FSEDT4RS3BLH3SCPDUPTZHPXBVDK5QPE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> 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=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=regexp --- Original Message --- On Monday, March 14th, 2022 at 8:56 AM, Chris Angelico wrote: > On Mon, 14 Mar 2022 at 23:54, Christopher Barker python...@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. > > 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 > > ___ > > 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/MAQMGRBZWFIWENTVOH6SHM6VD6XHSVDQ/ > > 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/CZ3AVWNJIUMQ6735MT4LA4CT6CKEE3RX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
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=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=regexp --- Original Message --- On Monday, March 14th, 2022 at 8:39 AM, Brendan Barnwell wrote: > On 2022-03-11 12:03, wfdc via Python-ideas wrote: > > > > I've used Python for 23+ years now. I've had occasion where I'd use this > > > methods maybe in the low-tens of times. > > > > > > I'd call the purpose rare at best. > > > > This comment is useless without a base rate. What's the base rate for > > > > comparable methods that are part of the standard library, like index > > > > and count? > > You seem to be implicitly suggesting that we should implement all > > methods that are at least as useful (or frequently needed, or whatever) > > as existing methods. I have some sympathy with this view, but you seem > > to be taking it to an unrealistic level. There are many things that > > have been added to Python over time that are now less useful than other > > things, for various reasons. We can't just draw a line and say "because > > .some_method() already exists and has a usefulness score of X, anything > > that is more useful must now be added" (even if it were possible to > > define such a usefulness score). Moreover, to do so would only lead to > > a spiral of madness, since by this logic someone else could come along > > and say "well, we added .replace() to tuples and I never need that, so > > there's no reason not to add this other new method most people won't > > care about or use." > > As far as I can see, you don't seem to be providing many substantive > > arguments in favor of your proposal. All you are saying is that > > sometimes it might be useful, and that there are other existing methods > > that aren't super useful, so why not add this one too? To me that is > > sort of like suggesting that it would be good to add a coffee machine > > and a swimming pool to my car, because my car already has a cigarette > > lighter and a little storage flap on the sun visor and I don't use > > those, so there's no reason not to add other random stuff as well. > > That isn't a very convincing argument. In deciding whether to add some > > feature to a car, what's relevant is not what other features my car > > already has that I'm not using, but how much it will cost (in time, > > money, user confusion, etc.) to add the feature relative to how much > > benefit it will bring. > > Similarly, what you are not providing is any consideration of the > > costs of adding this feature relative to the benefit. These costs > > include implementation and maintenance, increased API surface area for > > users to familiarize themselves with, and cluttering the type's > > namespace with yet another method name (even though you seem to > > acknowledge that it's already cluttered with methods that aren't very > > useful). Against that we have the benefit of being able to effectively > > "assign" to a tuple element, which is not zero but also not exactly a > > burning need. I don't think you're going to get much traction on this > > suggestion unless you at least engage with this idea of cost and > > benefits of your proposed feature itself, rather than just focusing on > > what you perceive as the low utility of things that are already part of > > Python. > > -- > > Brendan Barnwell > > "Do not follow where the path may lead. Go, instead, where there is no > > path, and leave a trail." > > --author unknown > > ___ > > 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/EKWLL4RYWP7YFW4MEO7ANRQ6CNPX25DF/ > > 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/V73PRCK54RF2OI4PFBCRK7URHHH376ZQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> wfdc (should we call you something which is not a random-looking string of > consonants?) wfdc is fine. > it might help if you could give examples of this functionality from other > languages or classes. What do they call the method? https://clojuredocs.org/clojure.core/assoc https://immutable-js.com/docs/v4.0.0/set()/ http://swannodette.github.io/mori/#assoc https://hackage.haskell.org/package/lens-5.1/docs/Control-Lens-Operators.html#v:.-126- https://hackage.haskell.org/package/containers-0.6.5.1/docs/Data-Sequence.html#update What about 'update' or 'set'? > what if index assignment was an expression? [...] Now that I have seen this > syntax, I want it!!! Interesting idea. Perhaps we can discuss it further. --- Original Message --- On Monday, March 14th, 2022 at 8:38 AM, Steven D'Aprano wrote: > On Fri, Mar 11, 2022 at 01:38:57AM +, Rob Cliffe via Python-ideas wrote: > > > This could cause confusion because str.replace() has a completely > > > > different API. > > The old "painter.draw()" versus "gun_slinger.draw()" problem. > > It does exist, but it's not generally a major problem. > > > And indeed if a replace method were added to tuples, a fair case could > > > > be made for it having the same API, viz. > > > > replace(old, new, count=-1) > > A reasonable suggestion. Does replace change items according to their > > position, or their value? > > Perhaps a better name would help. > > wfdc (should we call you something which is not a random-looking string > > of consonants?) it might help if you could give examples of this > > functionality from other languages or classes. What do they call the > > method? > > It would be nice to have a better API for this function. I have used it > > many times, for strings, lists and tuples, it is really a generate > > sequence operation: > > * make a copy of the sequence, replacing the item at position p with a > > new value; > > We can do it with type-specific expressions: > > seq[:p] + [value] + seq[p+1:] > > seq[:p] + (value,) + seq[p+1:] > > string[:p] + "c" + string[p+1:] > > but there is no good, type-agnostic way to easily do it. > > Wacky thought: what if index assignment was an expression? > > function(arg, seq[p]=value, another_arg) > > would pass a copy of seq with the item at p replaced by value. That > > would work with slices as well: > > seq[a:b] = values > > Now that I have seen this syntax, I want it!!! > > (It is not clear to me if this would be compatible to the existing > > `setitem API.) > > > Whereas your suggestion can be written as a simple 1-liner, as you > > > > demonstrate. So there is no strong need for a new method for it. > > Sure, not all one-liners need to be built-in. But some do. > > -- > > 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/HKYHO35W5M3LKUGUZ6MRYVVEIKUQ5XHC/ > > 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/R3GVWUZFQEMDY45FDKL536IXI7WX4A34/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> 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. Like I said, this puts it in the top 3031 / 1908740 = 0.00159 = 0.159% of Python questions by vote count. That's not "a low number of votes" no matter how you try to spin it. > Popularity on StackOverflow is just a vague indication of popularity, not a > sign of need or usefulness. Then 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=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=regexp for plenty more examples. > Is this part of the tuple class alone? > Or part of the Sequence ABC? Why or why not? Tuple alone, but I'm open to the latter. > What arguments does it take (index, slice, tuple of indicies)? Index, as specified in the OP. (Again, open to discussion.) > Any error conditions, what exceptions will be raised? I suggest raising an IndexError when the index is out of range. > Can we use it to delete an item (replace it with nothing at all)? No. > justification for why a simple one-line function isn't sufficient. See Christopher Barker's response. (Yes, efficiency is important.) See also the "batteries included" point that was made ages ago. (If users find themselves re-implementing the same utility function over and over again across different projects, it's a good sign that such a function should be part of the standard library.) Your other questions are frankly not necessary to answer and feel like goalpost-moving. The two proposals you held up as examples don't even satisfy them. --- Original Message --- On Monday, March 14th, 2022 at 8:32 AM, Steven D'Aprano wrote: > On Fri, Mar 11, 2022 at 07:12:49PM +, 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 > >
[Python-ideas] Re: Add a replace method to tuples
On Tue, 15 Mar 2022 at 03:16, wfdc wrote: > > Yes, and dataclasses and namedtuples support this concept very nicely. You > > still haven't shown why neither works. > > 1. They're less efficient, as Christopher pointed out long ago. > > 2. They're not sequences, so conceptually the wrong tool for the job. > A namedtuple IS a sequence. It is a tuple. They are deliberately designed to be drop-in replacements for tuples. ChrisA ___ 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/OYMJH6445PZ2P4LE5SGLH3QKXV2FHNH5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
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=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=regexp --- Original Message --- On Monday, March 14th, 2022 at 8:31 AM, Chris Angelico wrote: > 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 > > ___ > > 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/Q7OP5GSX5QZRCFVKDMUR6Q54KVGAOEEV/ > > 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/CTDIISRREQNS74FVKGLEA5Q3624H322Z/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
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=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=regexp > Yes, and dataclasses and namedtuples support this concept very nicely. You > still haven't shown why neither works. 1. They're less efficient, as Christopher pointed out long ago. 2. They're not sequences, so conceptually the wrong tool for the job. > it definitely seems like a good use-case for a dataclass. See above. > Repeatedly stating that it has to be immutable, has to not be a namedtuple, > has to not be a dataclass, and has to have a replace method, doesn't make it > true. See above. --- Original Message --- On Monday, March 14th, 2022 at 8:30 AM, Chris Angelico wrote: > On Sat, 12 Mar 2022 at 07:38, wfdc w...@protonmail.com wrote: > > > > you haven't shown us what your use-case actually is > > > > Any use-case where you'd want to modify an entry of an immutable sequence. > > That doesn't answer the question any more than your original code > > does. You're still starting with the assumption that you want to use a > > tuple, and using that as proof that you need to use a tuple. > > Show us your ACTUAL use case, your actual code, and why you can't use > > either a list or a namedtuple. Stop assuming that you are correct > > before you begin, because we don't agree that a tuple is necessary. > > You have not shown us any code, only made this repeated assertion and > > then wondered why we don't believe you. > > > Modifying an immutable datastructure is not a contradictory statement. In > > fact, there's a whole literature on it. See > > > > https://en.wikipedia.org/wiki/Purely_functional_data_structure > > > > https://en.wikipedia.org/wiki/Persistent_data_structure > > Yes, and dataclasses and namedtuples support this concept very nicely. > > You still haven't shown why neither works. > > > As Marco Sulla pointed, out, "Performance apart, this will allow you to > > code in functional style more easily." > > > > namedtuple's ._replace method is an existing example (as is record updating > > in Haskell, which is a purely functional language, with the attending > > benefits of immutability). > > > > For me specifically, my latest use-case is in a game-theoretic setting > > where the tuple represents a strategy profile. But the details of that > > would take us far beyond the scope of the discussion. > > I don't understand how a strategy profile has to be a tuple. In fact, > > particularly since you're wanting to replace one part of it, it > > definitely seems like a good use-case for a dataclass. > > > > whether it would actually be more appropriate for a list instead > > > > Lists are not immutable, so they fail the criteria. > > Why? > > Do you see how you are still failing to show any actual code, and thus > > any actual demonstration of why a tuple is necessary? > > Repeatedly stating that it has to be immutable, has to not be a > > namedtuple, has to not be a dataclass, and has to have a replace > > method, doesn't make it true. > > ChrisA > > ___ > > 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/6MZTLI4I42ZEDJATKM5WDYHMSNEOW6IH/ > > 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/VKCBA6CM3YTW4F6PPJIPEALIZI6FZUGE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: An unambiguous way of initializing an empty set and dictionary
Do you know what else would work for being able
to enter empty sets?
A prefix to {} , like "s"
a = s{}
and
b = f{}
for an empty frozenset
(/me ducks, and hides in a place Chris won't find me)
On Mon, Mar 14, 2022 at 10:29 AM Chris Angelico wrote:
> On Tue, 15 Mar 2022 at 00:07, Joao S. O. Bueno
> wrote:
> >
> >
> >
> > On Mon, Mar 14, 2022 at 9:49 AM Chris Angelico wrote:
> >>
> >> On Mon, 14 Mar 2022 at 23:35, wrote:
> >> >
> >> > Currently:
> >> > l = [] # new empty list
> >> > t = () # new empty tuple
> >> > s = set() # new empty set (no clean and consistent way of
> initializing regarding the others) <<<
> >> > d = {} # new empty dictionary
> >> >
> >> > Possible solution:
> >> > s = {} # new empty set
> >> > d = {:} # new empty dictionary (the ":" is a reference to key-value
> pairs)
> >>
> >> Nope, that would break tons of existing code. Not gonna happen.
> >
> > Of couse not. (And I mean it).
> > - but what about keeping what exists and adding {,} for an empty set?
> > (it is not that unlike the one-element tuple, which already exists)
>
> That's more plausible. However, the one-element tuple is actually
> written like this:
>
> t = x,
>
> The parentheses are a common form of clarity (and included in the
> repr), but aren't actually the part of the syntax that makes it a
> tuple - the comma is. So there's no real parallel, and it's basically
> "what can we write that wouldn't be ambiguous?", which is a weak
> justification.
>
> Unfortunately, Python simply doesn't have enough symbols available.
> Using precisely one opener/closer for each type is highly limiting,
> since the only characters available are those on a US-English keyboard
> and in the ASCII set. It would be nice if, for instance, ∅ could mean
> "new empty set", but then we'd need a way to type it, and it'd end up
> coming right back around to "just type set(), it's easier".
>
> I wonder what it would be like to have a fork of Python that
> introduces some non-ASCII non-US-English syntax, purely to give people
> a chance to play around with it. Someone might actually set up an
> editor feature so that "set()" transforms into "∅", not just visually
> but in the file, and since it's restricted to an input feature in the
> editor, it avoids the usual problems of "what if you shadow the name
> set". Who knows? Maybe it would catch on, maybe it wouldn't.
>
> It's not all that difficult to hack on Python and add this feature. I
> did it a while back, but since I didn't use sets enough to bother
> figuring out an input method, didn't end up using it. If you want to
> write it as a pure source-code transformation, {*()} is a syntax-only
> way to generate an empty set, so it'll guarantee that you don't run
> into name shadowing issues; but it would be better to make it actual
> syntax (and thus avoid unpacking a tuple into your set for no reason),
> and also change the repr accordingly.
>
> ChrisA
> ___
> 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/NYNTWQKJM4NOC72UPHVTUOUFCECYMZNW/
> 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/3465RMUBJBH453BNS4L2F7JCFYYWKBNA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
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-mentors...@python.org will give you help on that with a minimum of backseat driving. wfdc via Python-ideas writes: > 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=regexp 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 ___ 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/PY5ZKFFTMLDDMTA7WG3656NNEMHEFPJ3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: An unambiguous way of initializing an empty set and dictionary
On Tue, 15 Mar 2022 at 00:07, Joao S. O. Bueno wrote:
>
>
>
> On Mon, Mar 14, 2022 at 9:49 AM Chris Angelico wrote:
>>
>> On Mon, 14 Mar 2022 at 23:35, wrote:
>> >
>> > Currently:
>> > l = [] # new empty list
>> > t = () # new empty tuple
>> > s = set() # new empty set (no clean and consistent way of initializing
>> > regarding the others) <<<
>> > d = {} # new empty dictionary
>> >
>> > Possible solution:
>> > s = {} # new empty set
>> > d = {:} # new empty dictionary (the ":" is a reference to key-value pairs)
>>
>> Nope, that would break tons of existing code. Not gonna happen.
>
> Of couse not. (And I mean it).
> - but what about keeping what exists and adding {,} for an empty set?
> (it is not that unlike the one-element tuple, which already exists)
That's more plausible. However, the one-element tuple is actually
written like this:
t = x,
The parentheses are a common form of clarity (and included in the
repr), but aren't actually the part of the syntax that makes it a
tuple - the comma is. So there's no real parallel, and it's basically
"what can we write that wouldn't be ambiguous?", which is a weak
justification.
Unfortunately, Python simply doesn't have enough symbols available.
Using precisely one opener/closer for each type is highly limiting,
since the only characters available are those on a US-English keyboard
and in the ASCII set. It would be nice if, for instance, ∅ could mean
"new empty set", but then we'd need a way to type it, and it'd end up
coming right back around to "just type set(), it's easier".
I wonder what it would be like to have a fork of Python that
introduces some non-ASCII non-US-English syntax, purely to give people
a chance to play around with it. Someone might actually set up an
editor feature so that "set()" transforms into "∅", not just visually
but in the file, and since it's restricted to an input feature in the
editor, it avoids the usual problems of "what if you shadow the name
set". Who knows? Maybe it would catch on, maybe it wouldn't.
It's not all that difficult to hack on Python and add this feature. I
did it a while back, but since I didn't use sets enough to bother
figuring out an input method, didn't end up using it. If you want to
write it as a pure source-code transformation, {*()} is a syntax-only
way to generate an empty set, so it'll guarantee that you don't run
into name shadowing issues; but it would be better to make it actual
syntax (and thus avoid unpacking a tuple into your set for no reason),
and also change the repr accordingly.
ChrisA
___
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/NYNTWQKJM4NOC72UPHVTUOUFCECYMZNW/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: An unambiguous way of initializing an empty set and dictionary
On Mon, Mar 14, 2022 at 9:49 AM Chris Angelico wrote:
> On Mon, 14 Mar 2022 at 23:35, wrote:
> >
> > Currently:
> > l = [] # new empty list
> > t = () # new empty tuple
> > s = set() # new empty set (no clean and consistent way of initializing
> regarding the others) <<<
> > d = {} # new empty dictionary
> >
> > Possible solution:
> > s = {} # new empty set
> > d = {:} # new empty dictionary (the ":" is a reference to key-value
> pairs)
>
> Nope, that would break tons of existing code. Not gonna happen.
>
Of couse not. (And I mean it).
- but what about keeping what exists and adding {,} for an empty set?
(it is not that unlike the one-element tuple, which already exists)
>
> ChrisA
> ___
> 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/PCPZPHCNXOW6ADAOUXY25MTRDNXI4EQI/
> 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/LLS7SPT4XHLDCSHHKK3ZKXTHKA4R2LMV/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: An unambiguous way of initializing an empty set and dictionary
On Mon, Mar 14, 2022 at 8:33 AM wrote:
> Possible solution:
> s = {} # new empty set
> d = {:} # new empty dictionary (the ":" is a reference to key-value pairs)
>
I have suggested over the years—as have probably dozens of other people
(maybe thousands)—that that would be a great spelling if Python were a
brand new language. But in reality, Python is 30+ years old, and billions
of lines of code use `{}` as an empty dict.
Historically, Python had dictionaries before it had sets, so there was more
than a decade in there where sets were not a thing you could spell at all.
A breaking change isn't something that's going to happen here.
--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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/7U4MOQ4O46MMJO6OA34ZGML7X2WRVFR3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On Mon, 14 Mar 2022 at 23:54, Christopher Barker 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. > > 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 ___ 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/MAQMGRBZWFIWENTVOH6SHM6VD6XHSVDQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On 11/03/2022 02:19, wfdc wrote: > This could cause confusion because str.replace() has a completely different API. We're talking about tuples here, not strings. Yes, I know, and tuples and strings are different. But *humans* can be confused by "replace" having a totally different API in different contexts. This suggests at least finding a different name for your proposed method. Saying that a method's API differs for a completely different type, especially when such a difference would be expected given the difference in types, is not a valid objection. > And indeed if a replace method were added to tuples, a fair case could be made for it having the same API, viz. replace(old, new, count=-1) Not sure what you mean by this. Please clarify. A function that replaced tuple elements by value rather than by index would no doubt be useful to somebody (not that I'm proposing it). So it could use the same API as str.replace(). > Whereas your suggestion can be written as a simple 1-liner, as you demonstrate. So there is no strong need for a new method for it. The same can be said for index and count, along with numerous other methods attached to Python's built-in types. Hm, off the top of my head, I could (I believe) write "count" as an (inefficient) 1-liner, but not "index". I suggest it's harder than you think. (Try it!) Something being simple to implement does not mean it shouldn't be built-in. See Python's "batteries included" philosophy. "Not every 1-line function needs to be a built-in". If users find themselves re-implementing the same utility function over again and over again across different projects, it's a good sign that such a function should be part of the standard library. Well, you are 1 user. Have you evidence that there are (many) others? Best wishes Rob Cliffe --- Original Message --- On Thursday, March 10th, 2022 at 8:38 PM, Rob Cliffe via Python-ideas wrote: This could cause confusion because str.replace() has a completely different API. And indeed if a replace method were added to tuples, a fair case could be made for it having the same API, viz. replace(old, new, count=-1) Whereas your suggestion can be written as a simple 1-liner, as you demonstrate. So there is no strong need for a new method for it. Best wishes Rob Cliffe On 10/03/2022 03:42, wfdc via Python-ideas wrote: Add a "replace" method to tuples that returnsa new tuple with the element at a given index replaced with a given value. Example implementation: def replace(self, index, value): return self[:index] + (value,) + self[index + 1:] See https://stackoverflow.com/questions/11458239/how-to-change-values-in-a-tuple for more context. Currently, tuples have 2 public methods: index and count. replace would be similarly easy to implement and similarly useful. Furthermore, it would be a natural counterpartto nametuple's _replace method. ___ Python-ideas mailing list --python-ideas@python.org To unsubscribe send an email topython-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived athttps://mail.python.org/archives/list/python-ideas@python.org/message/TIHIG74ADMMZRKRNGR2TDZSXIMM6N7JM/ 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/QXB2HFMGAWDEI7G56ULOZIMW7LHR5CRY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] X-Post: Adopting the concept of "Teams" (from PEP 8015)
This is basically an email asking for inputs on https://discuss.python.org/t/14210. It's not clear to me whether the expectation is that people post in two places or just one; so I'm going to avoid duplicating the contents here. TLDR from that proposal: PEP 8015 had proposed an SC + Core Developers + Teams model. Python's current governance model has the first two, while the third is something that we've informally organised into. Let's formalise the organisational structures we already have, change the names of various groups to "teams" and benefit from the clearer formal organisation + naming scheme. ___ 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/D223YI5YSGYDYEZA54IT6RAL6I5UZQC4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] An unambiguous way of initializing an empty dictionary and set
On 3/13/22 14:49, joao.p.f.batista...@gmail.com wrote:
> Currently:
> l = [] # new empty list
> t = () # new empty tuple
> s = set() # new empty set (no clean and consistent way of initializing regarding the
others) <<<
> d = {} # new empty dictionary
>
> Possible solution:
> s = {} # new empty set
> d = {:} # new empty dictionary (the ":" is a reference to key-value pairs)
>
> Current workaround at least for consistency:
> l = list() # new empty list
> t = tuple() # new empty tuple
> s = set() # new empty set
> d = dict() # new empty dictionary
>
> However, it doesn't feel right to not be able to initialize an empty set as
cleanly and
> consistently as lists, tuples and dictionaries in both forms.
This is a topic better fit to python-ideas.
--
~Ethan~
___
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/AHUHYKKSVXSAIVYVAMNZDLFJQI4BEJU5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
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.me...@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 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 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.me...@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-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/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 ___ 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/B5JNBZ4PAI6JW3HKZMPJLKQW5CFZH754/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: An unambiguous way of initializing an empty set and dictionary
On Mon, 14 Mar 2022 at 23:35, wrote:
>
> Currently:
> l = [] # new empty list
> t = () # new empty tuple
> s = set() # new empty set (no clean and consistent way of initializing
> regarding the others) <<<
> d = {} # new empty dictionary
>
> Possible solution:
> s = {} # new empty set
> d = {:} # new empty dictionary (the ":" is a reference to key-value pairs)
Nope, that would break tons of existing code. Not gonna happen.
ChrisA
___
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/PCPZPHCNXOW6ADAOUXY25MTRDNXI4EQI/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
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=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=regexp --- Original Message --- On Saturday, March 12th, 2022 at 1:41 AM, Christopher Barker 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 > 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. >> 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 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 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. > wrote: > >> On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas >> 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-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/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___ 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/HWTH4PCAF7NX75QJ3AYMKYGTOZ456Z3T/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] hashlib.sha256(file_obj)
Hi, TL;DR: you can read just the code snippets and the last paragraph. First of all, I'm assuming hashlib is used to calculate hashes of large files in production very very often, such that even small performance and usability improvements would make a huge difference. If you don't share this assumption, delete this email :-) Today, hashlib.update() accepts only a bytes(), and many StackOverflow answers include code like: sha256 = hashlib.sha256() with open(path) as f: while True: data = f.read(BUF_SIZE) if not data: break sha256.update(data) return sha256.hexdigest() This is problematic because not everybody knows this pattern, so many codebases will include code like: with open(path) as f: return sha256(f.read()).hexdigest() and, frankly, who can blame them. It is also problematic for performance reasons - even if we know to do the chunking thing, while hashing a large file, the GIL will be taken and released many times, and many buffers will be allocated and deallocated. As far as I can see, hashlib already has a lock per hash object and safely releases the GIL in update() with a long bytes(), so it would be safe to add an option for update()/new() to take a file pointer and do the chunked reading/updating with one static buffer with the GIL released throughout, so that this would be with open(path) as f: return sha256(f).hexdigest() We can discuss whether this is the best API or its preferable to have with open(path) as f: return sha256.from_file(f).hexdigest() or with open(path) as f: return sha256().update_from_file(f).hexdigest() but I submit that today many people try sha256(f).hexdigest() because they're used to e.g. json and csv accepting file objects, and that today passing a file object raises, so making both new() and update() accept file objects would be the most beginner-friendly and won't break anything. Knowing that there are a million tiny details that need to be... hashed out, and given that I'm willing to write the code, would the devs be receptive to something like this? Thanks, Aur ___ 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/IPJSGQE2ARAKS7NMS6667GUE33YZKHI4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
See also the following Sourcegraph query for examples of use of the second approach: 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=regexp Regex: =\s*list\([\w\.]+\)\s*\w+\[\w+\]\s*=\s*[\w\.]+\s*[\w\.]+\s*=\s*tuple\(\w+\) --- Original Message --- On Friday, March 11th, 2022 at 7:36 PM, wfdc wrote: > See the following Sourcegraph query for examples of use of this pattern: > > 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=regexp > > Regex: > \[\s*:\s*(i|j|k|ind|index)\s*\]\s*\+\s*\(.*\,\)\s*\+\s*[\w\.]+\[\s*(i|j|k|ind|index)\s*\+\s*1\s*:\s*\] > > --- Original Message --- > On Wednesday, March 9th, 2022 at 10:42 PM, wfdc wrote: > >> Add a "replace" method to tuples that returns a new tuple with the element >> at a given index replaced with a given value. Example implementation: >> >> def replace(self, index, value): >> return self[:index] + (value,) + self[index + 1:] >> >> See >> https://stackoverflow.com/questions/11458239/how-to-change-values-in-a-tuple >> for more context. >> >> Currently, tuples have 2 public methods: index and count. replace would be >> similarly easy to implement and similarly useful. >> >> Furthermore, it would be a natural counterpart to nametuple's _replace >> method.___ 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/VZGYZE5NLITFLRWQMLHWBBXYGJN5IMTN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On 11/03/2022 19:30, wfdc wrote: > I could (I believe) write "count" as an (inefficient) 1-liner, but not "index". I suggest it's harder than you think. (Try it!) How much harder? Can you post your candidate? It was you that said it could be a 1-liner. The burden of proof is on you, if you still want to argue the point. Rob Cliffe___ 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/65ENSOY6CYVVCXGR53OCK2KUEIW2ARCD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
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=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=regexp --- Original Message --- On Sunday, March 13th, 2022 at 1:55 AM, Stephen J. Turnbull wrote: > 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). > > > > This could cause confusion because str.replace() has a completely > > > > different API. > > > We're talking about tuples here, not strings. > > 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). > > > Saying that a method's API differs for a completely different type, > > > especially when such a difference would be expected given the > > > difference in types, is not a valid objection. > > 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 ___ 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/IJ2NBULRFTVCFQWU2ZE6KC5MWWB3ZYOM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: hashlib.sha256(file_obj)
It was brought to my attention that there is an open ticket for this. Moving discussion there: https://bugs.python.org/issue45150 Aur On Sun, Mar 13, 2022 at 6:19 PM Aur Saraf wrote: > Hi, > > TL;DR: you can read just the code snippets and the last paragraph. > > First of all, I'm assuming hashlib is used to calculate hashes of large > files in production very very often, such that even small performance and > usability improvements would make a huge difference. If you don't share > this assumption, delete this email :-) > > Today, hashlib.update() accepts only a bytes(), and many StackOverflow > answers include code like: > > sha256 = hashlib.sha256() > with open(path) as f: > while True: > data = f.read(BUF_SIZE) > if not data: > break > sha256.update(data) > return sha256.hexdigest() > > This is problematic because not everybody knows this pattern, so many > codebases will include code like: > > with open(path) as f: > return sha256(f.read()).hexdigest() > > and, frankly, who can blame them. > > It is also problematic for performance reasons - even if we know to do the > chunking thing, while hashing a large file, the GIL will be taken and > released many times, and many buffers will be allocated and deallocated. > > As far as I can see, hashlib already has a lock per hash object and safely > releases the GIL in update() with a long bytes(), so it would be safe to > add an option for update()/new() to take a file pointer and do the chunked > reading/updating with one static buffer with the GIL released throughout, > so that this would be > > with open(path) as f: > return sha256(f).hexdigest() > > We can discuss whether this is the best API or its preferable to have > > with open(path) as f: > return sha256.from_file(f).hexdigest() > > or > > with open(path) as f: > return sha256().update_from_file(f).hexdigest() > > but I submit that today many people try sha256(f).hexdigest() because > they're used to e.g. json and csv accepting file objects, and that today > passing a file object raises, so making both new() and update() accept file > objects would be the most beginner-friendly and won't break anything. > > Knowing that there are a million tiny details that need to be... hashed > out, and given that I'm willing to write the code, would the devs be > receptive to something like this? > > Thanks, > Aur > ___ 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/WZF5POSOP4A6N4YRY4KBHPCTIZBEVE2Z/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
See the following Sourcegraph query for examples of use of this pattern: 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=regexp Regex: \[\s*:\s*(i|j|k|ind|index)\s*\]\s*\+\s*\(.*\,\)\s*\+\s*[\w\.]+\[\s*(i|j|k|ind|index)\s*\+\s*1\s*:\s*\] --- Original Message --- On Wednesday, March 9th, 2022 at 10:42 PM, wfdc wrote: > Add a "replace" method to tuples that returns a new tuple with the element at > a given index replaced with a given value. Example implementation: > > def replace(self, index, value): > return self[:index] + (value,) + self[index + 1:] > > See > https://stackoverflow.com/questions/11458239/how-to-change-values-in-a-tuple > for more context. > > Currently, tuples have 2 public methods: index and count. replace would be > similarly easy to implement and similarly useful. > > Furthermore, it would be a natural counterpart to nametuple's _replace method.___ 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/AJ6HIDCV7JDSVFHUDU5444ZZ5KVR7SNI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
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. wrote: > On Fri, Mar 11, 2022, 6:19 PM wfdc wrote: > >>> 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. > > Gosh, I had no idea immutability could be useful! :-) > > https://openlibra.com/en/book/functional-programming-in-python___ 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/ACK3RHWYPSTXERAWSXVRN4NHZCCIPCY2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
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 ___ 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/3KDV6KBNEAUR7XCOHPKGYHAZLNSIHTJR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On 11/03/2022 21:33, wfdc wrote: How about something like def index(self, x): return next(i for i, a in enumerate(self) if a == x) Including start and end: def index(self, x, start=0, end=-1): return next(i for i, a in tuple(enumerate(self))[start:end] if a == x) No cigar. If the element is not found it raises StopIteration. It should raise ValueError. Rob Cliffe --- Original Message --- On Friday, March 11th, 2022 at 4:02 PM, Rob Cliffe wrote: On 11/03/2022 19:30, wfdc wrote: > I could (I believe) write "count" as an (inefficient) 1-liner, but not "index". I suggest it's harder than you think. (Try it!) How much harder? Can you post your candidate? It was you that said it could be a 1-liner. The burden of proof is on you, if you still want to argue the point. Rob Cliffe ___ 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/DTJUIFW6ZHGVVSCVWRLHV4PFGD5RBYNY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On Fri, Mar 11, 2022 at 01:38:57AM +, Rob Cliffe via Python-ideas wrote: > This could cause confusion because str.replace() has a completely > different API. The old "painter.draw()" versus "gun_slinger.draw()" problem. It does exist, but it's not generally a *major* problem. > And indeed if a replace method were added to tuples, a fair case could > be made for it having the same API, viz. > replace(old, new, count=-1) A reasonable suggestion. Does replace change items according to their position, or their value? Perhaps a better name would help. wfdc (should we call you something which is not a random-looking string of consonants?) it might help if you could give examples of this functionality from other languages or classes. What do they call the method? It would be nice to have a better API for this function. I have used it many times, for strings, lists and tuples, it is really a generate sequence operation: * make a copy of the sequence, replacing the item at position p with a new value; We can do it with type-specific expressions: seq[:p] + [value] + seq[p+1:] seq[:p] + (value,) + seq[p+1:] string[:p] + "c" + string[p+1:] but there is no good, type-agnostic way to easily do it. Wacky thought: what if index assignment was an expression? function(arg, seq[p]=value, another_arg) would pass a copy of seq with the item at p replaced by value. That would work with slices as well: seq[a:b] = values Now that I have seen this syntax, I want it!!! (It is not clear to me if this would be compatible to the existing `__setitem__ API.) > Whereas your suggestion can be written as a simple 1-liner, as you > demonstrate. So there is no strong need for a new method for it. Sure, not all one-liners need to be built-in. But some do. -- 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/HKYHO35W5M3LKUGUZ6MRYVVEIKUQ5XHC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On Fri, Mar 11, 2022, 6:19 PM wfdc wrote: > > 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. > Gosh, I had no idea immutability could be useful! :-) https://openlibra.com/en/book/functional-programming-in-python ___ 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/3TOPNZCWORHCR6CY272RRTBITFU54IFR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On 2022-03-11 12:03, wfdc via Python-ideas wrote: I've used Python for 23+ years now. I've had occasion where I'd use this methods maybe in the low-tens of times. I'd call the purpose rare at best. This comment is useless without a base rate. What's the base rate for comparable methods that *are* part of the standard library, like index and count? You seem to be implicitly suggesting that we should implement all methods that are at least as useful (or frequently needed, or whatever) as existing methods. I have some sympathy with this view, but you seem to be taking it to an unrealistic level. There are many things that have been added to Python over time that are now less useful than other things, for various reasons. We can't just draw a line and say "because .some_method() already exists and has a usefulness score of X, anything that is more useful must now be added" (even if it were possible to define such a usefulness score). Moreover, to do so would only lead to a spiral of madness, since by this logic someone else could come along and say "well, we added .replace() to tuples and I never need that, so there's no reason not to add this other new method most people won't care about or use." As far as I can see, you don't seem to be providing many substantive arguments in favor of your proposal. All you are saying is that sometimes it might be useful, and that there are other existing methods that aren't super useful, so why not add this one too? To me that is sort of like suggesting that it would be good to add a coffee machine and a swimming pool to my car, because my car already has a cigarette lighter and a little storage flap on the sun visor and I don't use those, so there's no reason not to add other random stuff as well. That isn't a very convincing argument. In deciding whether to add some feature to a car, what's relevant is not what other features my car already has that I'm not using, but how much it will cost (in time, money, user confusion, etc.) to add the feature relative to how much benefit it will bring. Similarly, what you are not providing is any consideration of the *costs* of adding this feature relative to the benefit. These costs include implementation and maintenance, increased API surface area for users to familiarize themselves with, and cluttering the type's namespace with yet another method name (even though you seem to acknowledge that it's already cluttered with methods that aren't very useful). Against that we have the benefit of being able to effectively "assign" to a tuple element, which is not zero but also not exactly a burning need. I don't think you're going to get much traction on this suggestion unless you at least engage with this idea of cost and benefits of *your proposed feature* itself, rather than just focusing on what you perceive as the low utility of things that are already part of Python. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown ___ 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/EKWLL4RYWP7YFW4MEO7ANRQ6CNPX25DF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
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). > > This could cause confusion because str.replace() has a completely > > different API. > > We're talking about tuples here, not strings. 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). > Saying that a method's API differs for a completely different type, > especially when such a difference would be expected given the > difference in types, is not a valid objection. 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 ___ 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/QDL76JVLFX7DALV6ZSPB5V2YCYQTK2HD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> 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
wrote:
> 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-as-described-in-the-documentation
> :
from collections import namedtuple
Point = namedtuple('Point', 'x,y')
p = Point(x=11, y=22)
p._replace(x=33)
> Point(x=33, y=22)
>
> There is no index (0, 1, 2 ...), instead there is a name.
>
> On 11/03/2022 21:43, wfdc via Python-ideas wrote:
>
>> Wrong.
>>
>> If you're not willing to make substantive contributions to this thread, I
>> suggest you refrain from posting further.
>
> That, it seems to me, is a pretty insulting thing to say to someone who, I
> would guess, has been using Python for decade(s) longer than you have.
> Likewise this which you wrote in another post:
>
> Do you see why it's useful to have immutability?
>
> Best wishes
> Rob Cliffe
>
>> --- Original Message ---
>> On Friday, March 11th, 2022 at 4:42 PM, David Mertz, Ph.D.
>> [](mailto:david.me...@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
[Python-ideas] Re: Add a replace method to tuples
Please. If we're now talking about specific exceptions, my replace isn't a one-liner either. I was clearly referring to actual functionality. If you want that specific exception, 2 lines are sufficient. --- Original Message --- On Friday, March 11th, 2022 at 4:45 PM, Rob Cliffe wrote: > On 11/03/2022 21:33, wfdc wrote: > >> How about something like >> >> def index(self, x): >> return next(i for i, a in enumerate(self) if a == x) >> >> Including start and end: >> >> def index(self, x, start=0, end=-1): >> return next(i for i, a in tuple(enumerate(self))[start:end] if a == x) > > No cigar. If the element is not found it raises StopIteration. It should > raise ValueError. > Rob Cliffe > >> > >> --- Original Message --- >> On Friday, March 11th, 2022 at 4:02 PM, Rob Cliffe >> [](mailto:rob.cli...@btinternet.com) wrote: >> >>> On 11/03/2022 19:30, wfdc wrote: >>> > I could (I believe) write "count" as an (inefficient) 1-liner, but not > "index". I suggest it's harder than you think. (Try it!) How much harder? Can you post your candidate? >>> >>> It was you that said it could be a 1-liner. The burden of proof is on you, >>> if you still want to argue the point. >>> Rob Cliffe___ 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/HWJYYAOUO5AV7W22DIHGEPAKGVYLOWBE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] An unambiguous way of initializing an empty set and dictionary
Currently:
l = [] # new empty list
t = () # new empty tuple
s = set() # new empty set (no clean and consistent way of initializing
regarding the others) <<<
d = {} # new empty dictionary
Possible solution:
s = {} # new empty set
d = {:} # new empty dictionary (the ":" is a reference to key-value pairs)
Current workaround at least for consistency:
l = list() # new empty list
t = tuple() # new empty tuple
s = set() # new empty set
d = dict() # new empty dictionary
However, it doesn't feel right to not be able to initialize an empty set as
cleanly and consistently as lists, tuples and dictionaries in both forms.
___
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/OPWEKLLGT6RWMEHC4SLEZ2LSRVCSS4GP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On Fri, Mar 11, 2022 at 07:12:49PM +, 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/
[Python-ideas] Re: Add a replace method to tuples
On Sat, 12 Mar 2022 at 07:38, wfdc wrote: > > > you haven't shown us what your use-case actually is > > Any use-case where you'd want to modify an entry of an immutable sequence. That doesn't answer the question any more than your original code does. You're still starting with the assumption that you want to use a tuple, and using that as proof that you need to use a tuple. Show us your ACTUAL use case, your actual code, and why you can't use either a list or a namedtuple. Stop assuming that you are correct before you begin, because *we don't agree* that a tuple is necessary. You have not shown us any code, only made this repeated assertion and then wondered why we don't believe you. > Modifying an immutable datastructure is not a contradictory statement. In > fact, there's a whole literature on it. See > https://en.wikipedia.org/wiki/Purely_functional_data_structure > https://en.wikipedia.org/wiki/Persistent_data_structure Yes, and dataclasses and namedtuples support this concept very nicely. You still haven't shown why neither works. > As Marco Sulla pointed, out, "Performance apart, this will allow you to code > in functional style more easily." > > namedtuple's ._replace method is an existing example (as is record updating > in Haskell, which is a purely functional language, with the attending > benefits of immutability). > > For me *specifically*, my latest use-case is in a game-theoretic setting > where the tuple represents a strategy profile. But the details of that would > take us far beyond the scope of the discussion. I don't understand how a strategy profile has to be a tuple. In fact, particularly since you're wanting to replace one part of it, it definitely seems like a good use-case for a dataclass. > > whether it would actually be more appropriate for a list instead > > Lists are not immutable, so they fail the criteria. Why? Do you see how you are still failing to show any actual code, and thus any actual demonstration of why a tuple is necessary? Repeatedly stating that it has to be immutable, has to not be a namedtuple, has to not be a dataclass, and has to have a replace method, doesn't make it true. ChrisA ___ 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/6MZTLI4I42ZEDJATKM5WDYHMSNEOW6IH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
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-as-described-in-the-documentation
:
|
>>> from collections import namedtuple||
>>> Point = namedtuple('Point', 'x,y')||
>>>||
>>> p = Point(x=11, y=22)||
>>>||
>>> p._replace(x=33)||
Point(x=33, y=22)|
||
|There is no index (0, 1, 2 ...), instead there is a name. |
On 11/03/2022 21:43, wfdc via Python-ideas wrote:
Wrong.
If you're not willing to make substantive contributions to this
thread, I suggest you refrain from posting further.
That, it seems to me, is a pretty insulting thing to say to someone who,
I would guess, has been using Python for decade(s) longer than you have.
Likewise this which you wrote in another post:
Do you see why it's useful to have immutability?
Best wishes
Rob Cliffe
--- Original Message ---
On Friday, March 11th, 2022 at 4:42 PM, David Mertz, Ph.D.
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 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.
wrote:
On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas
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 topython-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived
athttps://mail.python.org/archives/list/python-ideas@python.org/message/DUJND4AXSODQAKRMA7NYRYREBXBAZ635/
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/35JY6DKDIJPLB2S2RYJTUKRPXF5INCLX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On Sat, 12 Mar 2022 at 08:53, wfdc via Python-ideas 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 ___ 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/Q7OP5GSX5QZRCFVKDMUR6Q54KVGAOEEV/ Code of Conduct: http://python.org/psf/codeofconduct/
