Validity of collections.deque as collections.abc.Sequence

[einarwar]

Hi

Setup:
Python 3.12.3
Pyright 1.1.364
Pylance v2024.5.1

Take the following example

from collections import deque
from collections.abc import Sequence

d = deque([1,2,3,4,5])

def slicing_func_with_sequence(seq: Sequence[int]) -> Sequence[int]:
    return seq[1:-1]

print(my_slicing_func_with_sequence(d)) # Raises TypeError: index must be integer, not 'slice'

No type-issue is raised when trying to use a deque as an argument to a function that takes a Sequence. However a deque is not sliceable, but this is not "captured" within Sequence.

In the following, the input argument is typed as a deque:

from collections import deque
from collections.abc import Sequence
from typing import reveal_type

d = deque([1,2,3,4,5])

def slicing_func_with_deque(seq: deque[int]) -> deque[int]:
    x = seq[1:-1]
    reveal_type(x) # Type of "x" is "int"
    return x

Now two type errors are issued as expected, indicating that this indeed does not work:

Argument of type "slice" cannot be assigned to parameter "key" of type "SupportsIndex" in function "__getitem__"
  "slice" is incompatible with protocol "SupportsIndex"
    "__index__" is not present

Expression of type "int" is incompatible with return type "deque[int]"
  "int" is incompatible with "deque[int]"

While I am aware that wanting to slice a deque might not be the best design choice, i think should get some kind of warning when trying to do this. What seems to be the problem is that a Sequence is able to be sliced, but deque is a Sequence yet it cannot be sliced.

I am not sure if this is a pyright problem or rather a problem in typeshed, python or something that should be handled by e.g flake-8-bugbear

[erictraut]

This isn't a bug in pyright, which is working correctly given the type information provided to it.

This is arguably a bug in the implementation of deque which doesn't honor the Liskov Substitution Principle. The LSP is a fundamental rule in object-oriented programming, and deque is violating it. The deque class inherits from MutableSequence, but it doesn't implement all of the functionality of MutableSequence.

Type checkers like pyright and mypy will detect and report LSP violations like this, but in this case the maintainers of typeshed have suppressed the error with a # type: ignore comment. See here.

You could ask the typeshed maintainers if they can think of a better way to handle this, but I can't think of any off the top of my head.

You could also report this as a bug in stdlib's implementation of deque and see if the CPython maintainers are willing to fix it in Python 3.14.

[AlexWaygood]

I agree with everything Eric says here. It is unfortunate that the runtime implementation of deque claims to be a MutableSequence without fully implementing the interface. For context, adding slice support to deque has been proposed multiple times over the years, but each time it has been decided that the implementation complexity meant it wasn't worth the maintenance burden:

• Add slicing support to collections.deque python/cpython#61596
• deque.pop(index) is not supported python/cpython#85581
• Documentation for object.__getitem__ is over-specified. python/cpython#113313