I mean you could write these as: if stack[-3:] == [x, y, z]
and elif stack[-1:] == [t] But plenty of use cases still exist ( https://mail.python.org/archives/list/python-ideas@python.org/message/7W74OCYU5WTYFNTKW7PHONUCD3U2S3OO/) and I think we shouldn't need to keep talking about them. On Tue, Aug 25, 2020 at 2:54 PM Daniel. <danielhi...@gmail.com> wrote: > 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/PI5OFONYFTRZDZWOW4A462XAHWLYYPDT/ Code of Conduct: http://python.org/psf/codeofconduct/