# Add list.discard() and deque.discard() **URL:** \ **Category:** Ideas\ **Created:** [October 12, 2025, 8:14pm UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330 "2025-10-12T20:14:35Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![gerardw](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/gerardw/32/8739_2.png) [@gerardw](https://discuss.python.org/u/gerardw)\ **Post date:** [October 12, 2025, 8:14pm UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/1 "2025-10-12T20:14:35Z")
Sometimes you want to remove something collection if it’s in there. set → discard() dict → pop() list → requires checking first on try / except. deque → requires checking first on try / except. It’s a weird inconsistency and I’m not aware of any reason beyond tradtion. discard would be consistent with set and list and deque already have pop methods. ---
**Author:** ![JoBe](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jobe/32/26961_2.png) [@JoBe](https://discuss.python.org/u/JoBe)\ **Post date:** [October 12, 2025, 8:43pm UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/2 "2025-10-12T20:43:10Z")
Personal im +1 on this. Perhaps adding a `dict.discard` (same as `dict.pop`) would help it be the same name everywhere. But generally, great idea, I’ve found myself often implementing helpers doing this kind of stuff. ---
**Author:** ![Stefan2](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/stefan2/32/18492_2.png) [@Stefan2](https://discuss.python.org/u/Stefan2)\ **Post date:** [October 12, 2025, 8:45pm UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/3 "2025-10-12T20:45:48Z")
> [@gerardw](#): > > requires checking first on try / except. > **Or an elephant.** > > [Elephant in Cairo - Wikipedia](https://en.wikipedia.org/wiki/Elephant_in_Cairo) > > ```python > def discard(xs, x): > xs.append(x) > xs.remove(x) > if xs and xs[-1] is x: > xs.pop() > > xs = [1, 2, 3] > discard(xs, 3) > print(xs) > discard(xs, 3) > print(xs) > > ``` > > [Attempt This Online!](https://ato.pxeger.com/run?1=m72soLIkIz9vwYKlpSVpuhY3F6ekpimkZBYnJxalaFQU6yhUaFpxKQBBRbFeYkFBah5QVBMmUJSam1-WChPITAOKKSTmpQCpaF3DWIXMYoUKiGao-oL8Ag1NLi6gKluFaEMdBSMdBeNYLmTbjDW5Cooy80qAHE2cEhCnQl0MczkA) ---
**Author:** ![JoBe](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jobe/32/26961_2.png) [@JoBe](https://discuss.python.org/u/JoBe)\ **Post date:** [October 12, 2025, 8:52pm UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/4 "2025-10-12T20:52:20Z")
This works, but it’s both less readable and slower (assuming .remove, .pop, .append and .\_\_contains\_\_each take some time C). It’s complexed than it needs to be. Another thing this lacks are standards. `.append`, `.remove` are not guaranteed for, say a `Sequence[...]`). Just adding a simple `.discard` to all sequences would be easier. ---
**Author:** ![tim.one](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tim.one/32/282_2.png) [@tim.one](https://discuss.python.org/u/tim.one)\ **Post date:** [October 12, 2025, 9:21pm UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/5 "2025-10-12T21:21:19Z")
I think it’s actually stranger that the indexed sequence types support `.remove()` at all 😉. The `dict` and `set` types are “content-addressable”. Insertion and deletion work by object value, are `O(1)`, and can’t be indexed directly by ordinals. The indexed sequence types share none of those properties. > [@gerardw](#): > > It’s a weird inconsistency and I’m not aware of any reason beyond tradtion. It became “a tradition” because nobody cared enough about `sequence.discard(unwanted)` to press for it in the early years. Lack of compelling use cases. Things like `dict.pop(unwanted)` _were_ driven by frequently expressed need. `dict.pop()` in fact was added in Python 2.0, along with `dict.popitem()`. They didn’t exist from the start. I’m neutral on whether `sequence.discard()` is added now. Not an itch I have, but if enough others do, fine by me. ---
**Author:** ![Stefan2](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/stefan2/32/18492_2.png) [@Stefan2](https://discuss.python.org/u/Stefan2)\ **Post date:** [October 12, 2025, 9:28pm UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/6 "2025-10-12T21:28:25Z")
> [@JoBe](#): > > slower Only searches once, so can be twice as fast as “checking first”. And can be hundreds of ns faster than “try / except” when the value isn’t there. ---
**Author:** ![blhsing](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/blhsing/32/25812_2.png) [@blhsing](https://discuss.python.org/u/blhsing)\ **Post date:** [October 13, 2025, 1:52am UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/7 "2025-10-13T01:52:06Z")
> [@tim.one](#): > > I think it’s actually stranger that the indexed sequence types support `.remove()` at all 😉. > > The `dict` and `set` types are “content-addressable”. Insertion and deletion work by object value, are `O(1)`, and can’t be indexed directly by ordinals. > > The indexed sequence types share none of those properties. `sequence.remove` can be more efficient than `set.remove`/`dict.pop` when the size of a typical sequence for the specific use case is expected to be small, since sets and dicts require hashing first. Use cases for `sequence.discard` are not uncommon at all, including: > > > > > > So while yes it is easily worked around with a `try-except` block, it would still be a meaningful method to have. ---
**Author:** ![Paddy3118](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/paddy3118/32/1396_2.png) [@Paddy3118](https://discuss.python.org/u/Paddy3118)\ **Post date:** [October 13, 2025, 2:58pm UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/8 "2025-10-13T14:58:57Z")
> [@Stefan2](#): > > Or an elephant. I’ve learnt something new today, (despite it being dated 1989). Thank you 🙂 ---
**Author:** ![Stanfromireland](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/stanfromireland/32/10102_2.png) [@Stanfromireland](https://discuss.python.org/u/Stanfromireland)\ **Post date:** [October 14, 2025, 4:33pm UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/9 "2025-10-14T16:33:05Z")
For those curious, `list.discard()` can be implemented by removing a single line (i.e. raise `ValueError`) from the `list.remove()` implementation. [Here is a patch](https://github.com/python/cpython/compare/main...StanFromIreland:cpython:list-discard-impl.patch). ---
**Author:** ![tjreedy](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tjreedy/32/137_2.png) [@tjreedy](https://discuss.python.org/u/tjreedy)\ **Post date:** [October 15, 2025, 4:05pm UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/10 "2025-10-15T16:05:58Z")
> [@blhsing](#): > > So while yes it is easily worked around with a `try-except` block, it would still be a meaningful method to have. I suspect that some of the ‘remove’ examples could now use a set rather than a list, but predate that addition, or wrap OS functions that return (short) lists. > [@Stanfromireland](#): > > `list.discard()` can be implemented by removing a single line (i.e. raise `ValueError`) from the `list.remove()` implementation. Rather than a new, near duplicate function, I would prefer a proposal to add a parameter to the existing list.remove to raise or not upon value absence (defaulting to True for back compatibility). ---
**Author:** ![Stanfromireland](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/stanfromireland/32/10102_2.png) [@Stanfromireland](https://discuss.python.org/u/Stanfromireland)\ **Post date:** [October 15, 2025, 4:53pm UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/11 "2025-10-15T16:53:21Z")
> Rather than a new, near duplicate function, I would prefer a proposal to add a parameter to the existing list.remove to raise or not upon value absence (defaulting to True for back compatibility). I think this would be inconsistent with the other API’s as mentioned in the original post. As for the implementation, that could be moved to a helper to deduplicate. Anyhow, if anyone wants to propose this as a PEP, (I myself would find it useful, though not particularly important) I am happy to help write it/co-author. ---
**Author:** ![Stanfromireland](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/stanfromireland/32/10102_2.png) [@Stanfromireland](https://discuss.python.org/u/Stanfromireland)\ **Post date:** [October 26, 2026, 5:20pm UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/12 "2026-10-26T17:20:08Z")
I have opened [an issue](https://github.com/python/cpython/issues/160724) to add `list.discard`. ---
**Author:** ![Sciolist](https://avatars.discourse-cdn.com/v4/letter/s/7bcc69/32.png) [@Sciolist](https://discuss.python.org/u/Sciolist)\ **Post date:** [October 26, 2026, 6:43pm UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/13 "2026-10-26T18:43:20Z")
(I have lurked for years and this is topic that is making me sign up after all this time. Apologies ahead of time for being a grouch!) I would like to see a PEP properly justifying adding this before it is added because I am not sure it is a good idea anymore after reading this while trying to fall asleep and waking up. I fear its presence will have a negative impact on code quality and understandability of the best way to do certain things in Python. My thoughts aren’t very clearly phrased, but I want to share them before it is ‘too late’ and this ends up in Python and it takes too much effort to roll back only for people to later wonder ‘why didn’t we think about it a bit more?’ which is a feeling I’ve had a couple of times seeing how changes crystallized since Python 3 initially came out. My first concern is that with a dict and set, you are dabbling in a bag of unique items. Trying to discard something that is already there just means you are ensuring it isn’t in the set going forward. For a list/deque, you either remove multiple items which is not expected for some users since the naming implies removing a single item, or remove only the first sometimes, leaving a scenario where that item is still in the list/deque, creating a subtle bug where people think they had made sure that item would not be in the container. The `remove` name very clearly signals a difference in behavior compared to `discard`, especially when mixing sets and lists in the same code. The operation may be similar, but the usable outcomes differ strongly. Explicitly handling the ‘failure to remove’ is preferable to me because it makes clear one object is not like the other. My second concern is more about algorithmic complexity of actions becoming more hidden. I don’t like hiding that complexity. Using `remove` has in my mind become a source of code smell, because it implies a linear search. If I see it used in code, I immediately feel the ‘position’ is likely to matter, which brings with it the penalties of dealing with such ordering. Note that if the position didn’t matter but I wanted to track duplicates, I would use a `dict` with a `key:count` mapping instead! With those arguments in mind, I would vastly prefer `list.remove_all` as a non-throwing alternative rather than re-using the`discard` name for lists, and vehemently opposite any form of `list.discard` especially where it concerns only a single item removal.. It preserves the hint towards algorithmic complexity for that family of positional data structures, and it avoids the bug-ridden pitfall of having a single-item discard-lookalike that leaves the list in an unknown state people are unlikely to consider. Finally, I also feel this difference will be beneficial to people who use Python to start with coding. The discussion of ‘why does list.discard not exist, but list.remove\_all does despite their similarity’ is something one can learn from. With the same name, I would argue it would even inhibit critical thinking to some degree, which is already ballooning as a big problem in this age of ease-of-use touchscreen devices and AI. ---
**Author:** ![Stanfromireland](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/stanfromireland/32/10102_2.png) [@Stanfromireland](https://discuss.python.org/u/Stanfromireland)\ **Post date:** [October 26, 2026, 9:02pm UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/14 "2026-10-26T21:02:26Z")
Thanks for your thoughts. 🙂 > [@Sciolist](#): > > For a list/deque, you either remove multiple items which is not expected for some users since the naming implies removing a single item, or remove only the first sometimes, leaving a scenario where that item is still in the list/deque, creating a subtle bug where people think they had made sure that item would not be in the container. This concern is understandable, but in my opinion it is a documentation problem rather than a design problem. The docs make the outcome explicit rather than silent. Furthermore, anyone who reads `discard()` as “ensure not present” on a list has the same misreading available for `remove()` today, and from what I have heard, that has not been a notable source of bugs. > [@Sciolist](#): > > algorithmic complexity of actions becoming more hidden. I do not think `discard()` is more hidden than `remove()`. However, in the PR I propose to document them both on the [time complexity page](https://docs.python.org/3.16/builtins/time-complexity.html). > [@Sciolist](#): > > I would vastly prefer `list.remove_all` as a non-throwing alternative rather than re-using the`discard` name for lists `remove_all()` is a different operation with its own use cases. It does not replace the common “remove it if it is there” pattern that `discard()` is for, so I don’t see them as alternatives to each other. If there is demand for removing all occurrences, a `count` parameter on `remove()`/`discard()`, like `str.replace()` has, could be considered in the future, and would fit naturally on top of this. ---
**Author:** ![Sciolist](https://avatars.discourse-cdn.com/v4/letter/s/7bcc69/32.png) [@Sciolist](https://discuss.python.org/u/Sciolist)\ **Post date:** [October 26, 2026, 11:21pm UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/15 "2026-10-26T23:21:55Z")
> [@Stanfromireland](#): > > This concern is understandable, but in my opinion it is a documentation problem rather than a design problem. The docs make the outcome explicit rather than silent. I accept your viewpoint, but I unfortunately disagree. Code that self-documents its correctness is the best code and I feel we already have the explicit outcome for `discard` that this is proposing to take away. If I have some variables and I do ```python # example code; I have plenty of similar snippets in codebases though # Remove x from current state self.options.discard(x) self.actions.discard(x) self.layers.discard(x) # silent footgun: x could still be in this list! # as opposed to self.options.discard(x) self.actions.discard(x) if x in self.layers: self.layers.remove(x) # explicitly removing only the first entry ``` then I lose the visual separation that I am dealing with different containers with different behaviors, and that the discard action has a different result compared to my expectation of them all being sets. (Maybe there is a linting hint that can identify it, but I personally view lint as a bandaid for mistakes that result from bad language design, so to me that is not a valid argument in this discussion as it puts the cart before the horse.) > [@Stanfromireland](#): > > `remove_all()` is a different operation with its own use cases. It does not replace the common “remove it if it is there” pattern that `discard()` is for, so I don’t see them as alternatives to each other. For over twenty years, I have mixed sets and lists in ways resembling this depending on my needs to track state. I `discard` things to make sure they aren’t present in my set. It is the only `discard` that Python’s structures have ever had, so it has taken that meaning by sheer usage. That is the underlying goal of why I use it, and the `set` implemented this implication and separation as early as Python 2.3. You can’t discard from a list because discarding is a set operation. Sure, it means exactly ‘remove one if it is there’ on a programmatic level, but for all these decades, the end result of this method has been “after running `s.discard(x)` the invariant `x not in s` is achieved”. It may not be in the docs like that, but it is what is expected. Between `set` and `list`, there is a clear distinction between `add` and `append`/`insert`because they have different meanings and results due to the positional nature of the list that does not apply to a set. Adding is ambiguous compared to appending for lists, and appending has no meaning for a set. So why can we not have a different name for a `list.discard`to sidestep this entire issue? I’m all up for a bunch of bikeshedding as to what would be proper, but even if the implementation is nearly the same, I do not believe that the people using it will have the same expectations of the things it achieves. To be clear: I completely understand the benefits of this functionality in terms of speed and avoiding the penalty of a`try` or `if` statement to accomplish the same thing. I just don’t believe that the argument that ‘it is documented’ is sufficient reason to have a footgun facing you in your code that we can easily avoid. The fact my editor and Python yell at me when I try to `discard` a list has saved me numerous times from making the mistake that you now argue can be avoided by reading the documentation. I _know_ what the functions do and always have, but easily _seeing_ and confronting my mistakes as opposed to silently letting them happen is a huge gotcha. I feel the only thing accomplished now is that every `discard` in a codebase that does not check a return value is going to look like a potential code smell, because lists **will** need those checks most of the time (did we remove something, yes or no? Did such an entry remain afterwards, yes or no?) while for sets they are pointless. From where I am standing, `list.discard`as proposed is looking like it will have tricky edge cases resulting akin to many of the C string library functions (length off by ones) that people will tend to not handle properly (except with leftover entries because they thought the list was a set). The only thing that can make those functions remotely safe is if you have to treat them everywhere equally, but the way to deal with the aftermath of`discard` will differ depending on the container. To me, it feels like we are 20 years too late to implement `discard` on other containers that have wildly different implications on what they factually accomplish. The only container that has ever had it is `set`, so I think the practical way `set.discard` has been used and expectations of it are very much the definition of what `discard` is for. I’m sorry if I’m too passionate or wordy, by the way! Succinctness is not something I’m good at. 🙂 TL;DR: `container.discard` has always been safe and predictable, `container.remove` has always needed attention of some kind… and now we propose to make both of them take pointless brainpower away from the real problems to guard against a new kind of footgun where we mentally apply `set`expectations on a `list` container. Please keep Python simple to reason about. ---
**Author:** ![gdchinacat](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/gdchinacat/32/37254_2.png) [@gdchinacat](https://discuss.python.org/u/gdchinacat)\ **Post date:** [October 27, 2026, 12:50am UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/16 "2026-10-27T00:50:50Z")
To make sure I understand your concerns, one is that `set.discard()` is O(1) while `list.discard()` would be O(N). The other concern is that up until now `discard()` has been isolated to `set` and has the (not explicitly documented) invariant that `s.discard(x); assert x not in s`, and a`list.discard()` will not have this invariant? Would it be fair to summarize your position that adding `dict.discard()` and `list.discard()` will not actually provide a unified/common operation because the semantics will be fundamentally different? ---
**Author:** ![Sciolist](https://avatars.discourse-cdn.com/v4/letter/s/7bcc69/32.png) [@Sciolist](https://discuss.python.org/u/Sciolist)\ **Post date:** [October 27, 2026, 2:20am UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/17 "2026-10-27T02:20:22Z")
> [@gdchinacat](#): > > To make sure I understand your concerns, one is that `set.discard()` is O(1) while `list.discard()` would be O(N) Regarding algorithmic complexity, that is roughly it. I consider it an optimized operation that perfectly matches set semantics, whereas `remove`identifies a more generic removal operation that can be implemented as an expensive search with a variety of extra complexity depending on the data structures characteristics. If I see `list.remove` used, I usually check whether I might already have the index so I can `del`it instead. It is for the same reason that I try to structure my code to avoid `list.insert` so that I can use `list.append` instead. There’s nothing wrong with the capability since you need it sometimes, but it is not the desired way to interact with the data structure. If you have an index handy already, you’d usually want `del` to be most efficient about your deletion! In the same vein, offering an alternative to the technically already less-ideal `list.remove` that performs similarly except sounds like a more efficient set seems like it not only muddies the water of the specialized operation of `set.discard`, but also encourages wrong usage of the `list` data structure. Given how ubiquitous lists are in every part of Python compared to sets, I’m not sure that is desired. I always liked the fact that the operations subtly steer me into thinking properly about the right way to use them due to the operations they support. Actively supporting alternative modes of less-optimal access goes counter to that in the name of what is really nothing more than a convenience function that will have its fair share of surprises that `list.remove` already forces us to actively consider. > [@gdchinacat](#): > > The other concern is that up until now `discard()` has been isolated to `set` and has the (not explicitly documented) invariant that `s.discard(x); assert x not in s`, and a`list.discard()` will not have this invariant? Exactly. Depending on the kind of implementation of `list.discard`, there is either… **Remove the first found item (like `remove`),** resulting in - Item not in list, nothing changes, maybe returning a value to say nothing was removed, item not in list, OR… - Item in list one time, item is removed, returning a value to say something was removed, item not in list, OR… - Item in list multiple times, first item is removed, returning a value to say something was removed, item remains in list. If someone wants to remove all the items from the list, you might end up with intuitive yet badly performing code like ```python while apples.discard(rotten): pass # a new search for every iteration ``` **Remove all occurrences of item (to approximate `set.discard`),** resulting in - Iterate over entire list, items removed one by one, likely optimized to minimize unnecessary shuffling, no more item in list. If for every occurrence in my code of `variable.discard(x)`I need to start wondering whether it is a list and what result the three possible outcomes will have on my code, I end up with both extra cognitive load, and with me frequently putting in the sort of boilerplate we are already expecting from `list.remove`except differently. The benefit of `list.remove` is that not thinking about the code paths and meaning is never an option; it is very much part of the contract. But the popular first option for `list.discard`is created primarily because people don’t want to deal with that complexity to begin with. Its intended existence is innately self-contradictory as a result, and we will exchange the burden of extra `if`/`try` checks for the uncertainty and confusion of whether we want and/or need to apply any kind of special handling at all in our logic. > [@gdchinacat](#): > > Would it be fair to summarize your position that adding `dict.discard()` and `list.discard()` will not actually provide a unified/common operation because the semantics will be fundamentally different? Exactly. We have survived 20+ years without `list.discard`, and adding this confusion to the mix for the sake of saving one line is a very daring and silly approach IMHO. If we want a non-throwing `list.remove`, I champion giving it a different name like `sequence.ditch`or some other reasonable synonym (`toss`?). While the three different varieties of possible outcomes would still be the same (and in my opinion still not desired), we would at least avoid all the confusion over set semantics, making that much a non-issue at least. ---
**Author:** ![Stanfromireland](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/stanfromireland/32/10102_2.png) [@Stanfromireland](https://discuss.python.org/u/Stanfromireland)\ **Post date:** [October 27, 2026, 10:57am UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/18 "2026-10-27T10:57:00Z")
This proposal has now been written up as [PEP 851](https://peps.python.org/pep-0851/), let’s continue this discussion in the PEP thread at [PEP 851: Add list.discard()](https://discuss.python.org/t/pep-851-add-list-discard/109701). ---
**Author:** ![davidism](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/davidism/32/3295_2.png) [@davidism](https://discuss.python.org/u/davidism)\ **Post date:** [October 27, 2026, 1:22pm UTC](https://discuss.python.org/t/add-list-discard-and-deque-discard/104330/19 "2026-10-27T13:22:34Z")