On Sun, Feb 23, 2020 at 01:46:53PM -0500, Richard Damon wrote: > I would agree with this. In my mind, fundamentally a 'string' is a > sequence of characters, not strings,
If people are going to seriously propose this Character type, I think they need to be more concrete about the proposal and not just hand-wave it as "strings are sequences of characters". Presumably you would want `mystring[0]` to return a char, not a str, but there are plenty of other unspecified details. - Should `mystring[0:1]`return a char or a length 1 str? - Presumably "Z" remains a length-1 str for backward compatibility, so how do you create a char directly? - Does `chr(n)` continue to return a str? - Is the char type a subclass of str? - Do we support mixed concatenation between str and char? - If so, does concatenating the empty string to a char give a char or a length-1 string? - Are chars indexable? - Do they support len()? If char is not a subclass of string, that's going to break code that expects that `all(isinstance(c, str) for c in obj)` to be true when `obj` happens to be a string. If char is a subclass, that means we can no longer deny that strings are sequences of strings, since chars are strings. It also means that it will break code that expects strings to be iterable, I don't have a good intuition for how much code will break or simply stop working correctly if we changed string iteration to yield a new char type instead of length-1 strings. Nor do I have a good intuition for whether this will *actually* help much code. It seems to me that there's a good chance that this could end up simply shifting isinstance tests for str in some contexts to isinstance tests for char in different contexts. Without a detailed proposal, I don't think we can judge how plausible this change might be. > so as you iterate over a string, > you shouldn't get another string, but a single character type (which > Python currently doesn't have). It would be totally shocking if someone > suggested that iterating a list or a tuple should return lists or tuples > of 1 element, so why do strings to this? Would it be so shocking though? If lists are *linked lists* of nodes, instead of arrays, then: - iterating over linked lists of nodes gives you nodes; - and a single node is still a list; which is not terribly different from the situation with strings. But in any case, lists are not limited to only containing other lists. That's not the case for strings. You couldn't get a dict or None contained in a string. Strings can only contain substrings, which include length-1 strings. -- Steven _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3KYVSKMLXCL2AU4YUXDAYHZBX3X4H4YP/ Code of Conduct: http://python.org/psf/codeofconduct/
