On Sun, 2020-02-23 at 20:32 +0000, jdveiga@gmail.com wrote:
Kyle Stanley wrote:
In order for this proposal to be seriously considered, I think it's necessary to cite many realistic examples where the current behavior is <snip> existing solutions, I strongly suspect that this is going to be the case of change that is far too fundamental to Python to be changed at this point, even with a distant deprecation warning and many years of advanced notice regarding the removal/change after that.
I agree. I can barely imagine what is wrong with Python's strings. Can you please provide any example?
The main issue is generic code. Sequence like lists and tuples are often iterated over: You work with the elements inside. However, in the same code, often strings are actually not desired to be handled as sequences. I.e. some code uses strings as sequences of characters, but most code probably uses the meaning that a string is a word, or sentence: the individual character has no useful meaning on its own.
It is a common "pattern" in any languages to walk along strings, letter by letter. Python's strings provide a powerful way of doing it --as a sequence which is a fundamental type in the language. No need to dealing with indexes, terminators, lengths, boundaries, etc. I love Python because of this and hate C's and Java's strings.
On the other hand, what about slices? Since slices operate in sequences and lists, if strings are not longer sequences, how would Python do slicing on strings according to your proposal?
I doubt anyone wants to touch slicing/indexing syntax, although that could lead to a mismatch in what we are used to. I.e. the string is not iterable?: for i in range(len(string)): character = string[i] might work where: for character in string: pass would tell you to use `for character in string.chars():` instead. If you make it a property rather than a function, you could think about also forcing `string.chars[0]` in the first case. Coming from NumPy, there is a subtle spectrum: * strings are primarily scalars for which sequence behaviour is well defined and often convenient * lists/tuples are typical collections/sequences * NumPy arrays are more element focused than most collections (operators modify the elements not the container). we also have some code that has to check for string explicitly in NumPy (it is not a big issue though). I am almost starting to wonder if a flag/ABC for each of the three cases could be useful: * isinstance(string, ScalarCollection) -> True * isinstance(list_, TypicalCollection) -> True * isinstance(NumPy_array, ElementwiseCollection) -> True to distinguish the spectrum. But, I doubt it myself for now. It is not duck-typing and in general what you want can be context dependent. Plus, likely strings are the main ScalarCollection in practice anyway. Polynomials come to mind, but there is only so many of those likely to mix. Best, Sebastian
I think strings as immutable strings is indeed a wise implementation decision on Python.
Thank you. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/PETKSM... Code of Conduct: http://python.org/psf/codeofconduct/