Skip to content

Conversation

@srittau
Copy link
Collaborator

@srittau srittau commented Dec 19, 2025

Sequence and Mapping are commonly used in argument types. This can
be problematic, since they are not protocols, making it impossible to
safely duck type or mock them. Also, not all sequence- or mapping-like
types derive from these ABCs at runtime, although in typeshed we often
pretend they do. Ideally we'd be able to avoid this discrepancy in the
far future. Finally, the ABCs sometimes make more API promises than
their sub-classes fulfill. For example, Mapping arguments are
keyword-or-positional, while its most important subtype dict only
accepts positional arguments. These protocols have tighter guarantees.

SequenceLike contains most, MappingLike all methods from their
respective types, making them an easy substitute in argument types.

srittau and others added 2 commits December 19, 2025 18:35
`Sequence` and `Mapping` are commonly used in argument types. This can
be problematic, since they are not protocols, making it impossible to
safely duck type or mock them. Also, not all sequence- or mapping-like
types derive from these ABCs at runtime, although in typeshed we often
pretend they do. Ideally we'd be able to avoid this discrepancy in the
far future. Finally, the ABCs sometimes make more API promises than
their sub-classes fulfill. For example, `Mapping` arguments are
keyword-or-positional, while its most important subtype `dict` only
accepts positional arguments. These protocols have tighter guarantees.

`SequenceLike` contains most, `MappingLike` all methods from their
respective types, making them an easy substitute in argument types.
@github-actions
Copy link
Contributor

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

@JelleZijlstra
Copy link
Member

Why should we use these rather than more precise protocols like SupportsGetItem?

@srittau
Copy link
Collaborator Author

srittau commented Dec 22, 2025

For convenience. I still think using the more precise protocols is the better option in 90% of cases, but sometimes this would be inconvenient, especially as long as we don't have easy protocol composition (via intersections). See also the large amount of Mapping and Sequence annotations we still have, which could easily be replaced with these protocols for now, and refined later.

@srittau
Copy link
Collaborator Author

srittau commented Dec 22, 2025

Also, cf. PyCQA/flake8-pyi#525

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants