On Thu, 24 Oct 2019 at 23:47, Andrew Barnert via Python-ideas
<[email protected]> wrote:
> But again, I don’t think either of these is the reason Python strings being
> iterable is a problem; I think it really is primarily about them being
> iterables of strings.
The *real* problem is that there's a whole load of functions that
would need rewriting to accept "character or string" arguments - or a
whole load of debating over whether they should only use one or
another. Examples:
"a" in char_string, vs "word" in sentence. Both useful and used in real code.
list_of_stuff.join(",") vs list_of_stuff.join(", ")
list_of_characters.join("")
And return values: string.partition(sep) - if sep is a character,
should the middle return value be a character too? Remember that the
typing module needs to be able to express the type signatures of all
these functions, in a way that usefully allows checking usage.
Plus many, many more. And not just in the stdlib, but in millions of
lines of 3rd party code.
And no cheating by saying these are cases where you should use
1-character strings. The fact that people don't typically distinguish
between characters and 1-character strings in real life is precisely
why it's useful that Python currently doesn't make a distinction
either.
In case it's not glaringly obvious, I'm -1 on this, even as an
exercise in speculation :-)
Paul
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/JCJPLI5UCPDUQCRNTMFJMII4E6EE27ZQ/
Code of Conduct: http://python.org/psf/codeofconduct/
