Oh, thanks :) Anyway, it still applies for fetching a single arbitrary indexes
Em ter., 25 de ago. de 2020 às 11:07, Alex Hall <alex.moj...@gmail.com> escreveu: > 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. >>> >> -- “If you're going to try, go all the way. Otherwise, don't even start. ..." Charles Bukowski
_______________________________________________ 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/JTRUNNK2NN6ALD33A4BQCE65TJN26AVP/ Code of Conduct: http://python.org/psf/codeofconduct/
