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.mojaki@gmail.com> escreveu:

On Thu, Jul 2, 2020 at 10:33 PM Alex Hall <alex.mojaki@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.