Here is one example added in stdlib https://github.com/python/cpython/pull/14813/files
It's checking the truthness of value before calling value[0], this is a perfect match for value.get(0) Here is another, just the same use case, https://github.com/python/cpython/pull/17515/files When you deal with parsing problems yielding sequence of tokens are pretty common and knowing how much tokens are there is a matter of input. When you deal with recursives problems using a stack too.. so there are use cases out there and it's a tiny change Em ter, 25 de ago de 2020 09:52, Daniel. <danielhi...@gmail.com> escreveu: > I just came across this again while implementing an parser > > I would like to compare stack elements as > > if stack[-3] == x and stack[-2] == y and stack[-1] == z > > and somewere below > > elif stack[-1] == t > > I had to spread `len(stack)` in a lot of places. > > People said about the length of a list is usually known, but when you use > it as a stack is the oposit. > > Em ter, 25 de ago de 2020 09:44, Alex Hall <alex.moj...@gmail.com> > escreveu: > >> On Thu, Jul 2, 2020 at 10:33 PM Alex Hall <alex.moj...@gmail.com> wrote: >> >>> On the other hand, `list.get` seems very doable to me. It's not new >>> syntax. It would be extremely easy to learn for anyone familiar with >>> `dict.get`, which is pretty much essential knowledge. You'd probably have >>> some people guessing it exists and using it correctly without even seeing >>> it first in other code or documentation. I haven't seen anyone in this >>> thread suggesting any cost or downside of adding the method, just people >>> asking if it would be useful. I feel like I answered that question pretty >>> thoroughly, then the thread went quiet. >>> >> >> I just had a coworker ask if there was something akin to `list.get(0)`, >> so I'd like to try to revive this. >> >> I propose that: >> >> 1. There is basically no cost in terms of mental capacity, learnability, >> or API bloat in adding list.get because of the similarity to dict.get. >> 2. There are plenty of times it would be useful, as seen in >> https://mail.python.org/archives/list/python-ideas@python.org/message/7W74OCYU5WTYFNTKW7PHONUCD3U2S3OO/ >> 3. If the above two points are true, we should go ahead and add this. >> >> I think that the discussion here simply fizzled away because: >> >> 1. People got distracted by talking about PEP 505 which really isn't very >> relevant and would solve a different problem. >> 2. There are no major objections, so there isn't much left to talk about, >> which seems like a silly way for a proposal to die. The only decent >> objection I saw was skepticism about valid and frequent use cases but once >> I answered that no one pursued the matter. >> >
_______________________________________________ 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/VWU4XVVTT3XAWFKFYFPRDLW3QDGF66TC/ Code of Conduct: http://python.org/psf/codeofconduct/
