Possibility for a char type

[tusharsadhwani]

I was wondering if the type system should add a char type: a subclass of str, and operations like __getitem__ on a str would return a char.

The major problem that this would solve is that currently you can pass a str where an Iterable[str] is expected, which has caused many bugs in my experience.

What are the potential downsides of such a subtype?

[srittau]

This is being discussed in #256. I think the overall consensus is that being able to distinguish between str and Iterable[str] would be a good idea, but there really isn't a good way to do it at the moment.

[hauntsaninja]

Not a complete solution to this set of problems, but noting there is useful_types.SequenceNotStr: https://github.com/hauntsaninja/useful_types/blob/main/useful_types/__init__.py#L285

[tusharsadhwani]

The discussion actually seems to show that a char type is probably better than status quo. Still a bit unclear on why it's not standardized.

[Daverball]

You're welcome to create a PR on typeshed to experiment with this, i.e. add Char = NewType('Char', str) use it as a return type for str.__iter__ and the int overload on str.__getitem__ (slice would still need to return str) and see what happens, mypy primer output would be especially relevant to gauge how much existing code this would break.

Actually on second thought, this probably wouldn't help at all, since Iterator/Iterable/Collection/Sequence are covariant. You would need to create a distinct type from str that's not a subtype of str, but I think that would break too much code and is unnecessarily strict.

It's worth noting that while passing str into Iterable[str] is probably usually a bug, it's also not unsafe, so arbitrarily restricting it seems wrong. This seems like a job for a linter or a type checker plugin, which emits a warning when it sees str being passed into Iterable[str]/Collection[str]/Sequence[str]