# Removing \`Sequence\[str\]\` as base class of \`str\`
**URL:** https://discuss.python.org/t/removing-sequence-str-as-base-class-of-str/56907
**Category:** Typing
**Created:** [June 28, 2024, 7:06pm UTC](https://discuss.python.org/t/removing-sequence-str-as-base-class-of-str/56907 "2024-06-28T19:06:25Z")
**Posts on this page:** 3
**Page:** 3
### Author:  [@timhoffm](https://discuss.python.org/u/timhoffm)
#### Post date: [May 29, 2025, 5:24am UTC](https://discuss.python.org/t/removing-sequence-str-as-base-class-of-str/56907/41 "2025-05-29T05:24:04Z")
> [@opk12](#):
>
> ```python
> def f(sentences: Iterable[str]):
> if 'Alice' in s.split():
> print("Found")
>
> f('Hello Alice') # subtle bug
> f('Hello Alice'.chars()) # easily spotted bug
>
> ```
The point is that a user will likely not _want_ to pass a sequence of chars and hence won’t use the easily spotted bug variant. They continue to use the subtle bug case, and the existence of `.chars()` does not help detecting the error there. You could add an option to type checkers to flag the deprecated `f('Hello Alice')`. That flag would have to be activated by the user globally, but the user cannot know whether all the libraries they use actually intend the stricter definition of `Iterable[str]`.
So, while a `chars()` method can be valuable for clarity, it does not solve the str vs Sequence[str] ambiguity mid-term.
---
### Author:  [@opk12](https://discuss.python.org/u/opk12)
#### Post date: [May 29, 2025, 10:04am UTC](https://discuss.python.org/t/removing-sequence-str-as-base-class-of-str/56907/42 "2025-05-29T10:04:36Z")
> So, while a `chars()` method can be valuable for clarity, it does not solve the str vs Sequence[str] ambiguity mid-term.
Sure there is a process to deprecate a language feature gradually? Or what about this.
1. The language documentation officially recommends that type checkers and linters do not treat `str` as iterable.
2. A `DeprecationWarning` is raised at runtime (opt-in).
3. Ruff and mypy implement an experimental, opt-in warning.
4. When more than a given % of pypi’s packages is OK for ruff and mypy, switch them to warn by default.
Point 4 is actually what happened in case of other warnings that were first implemented as opt-in and were later changed to opt-out.
> That flag would have to be activated by the user globally, but the user cannot know whether all the libraries they use actually intend the stricter definition of `Iterable[str]`.
Type checkers do not check the libraries, they check specific files or the user’s project. You raise a valid concern, which is not specific to the `str` issue being discussed here; one cannot or does not want to patch the library code. The concern has already been solved, tools have fine-grained configuration settings for file selection.
---
### Author:  [@timhoffm](https://discuss.python.org/u/timhoffm)
#### Post date: [May 30, 2025, 12:58am UTC](https://discuss.python.org/t/removing-sequence-str-as-base-class-of-str/56907/43 "2025-05-30T00:58:07Z")
The key point is that
> type checkers and linters do not treat `str` as iterable
Is a change in the type specification of str; for type checking concerns str no longer matches `Sequence[str]`. A library author would eventually specify `str | Sequence[str]` or just `Sequence[str]` depending on whether single strings are supported.
A user calling `f('Hello Alice')` will get an error as soon as the rule is applied (either through buy-in or default) - they must then decide whether their code is invalid and they have to change it, or whether the upstream definition of `f` has just not been updated, in which case, they would need to add an ignore. This is quite cumbersome, so I don’t expect early adoption from user side. The change has to first propagate though the libraries. That was the reason for my claim, that it does not solve the topic mid-term; I.e. not before your step 4.
[
[Previous page](https://discuss.python.org/t/removing-sequence-str-as-base-class-of-str/56907.md?page=2)