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.
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.
The language documentation officially recommends that type checkers and linters do not treat str as iterable.
A DeprecationWarning is raised at runtime (opt-in).
Ruff and mypy implement an experimental, opt-in warning.
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.
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.