On Sun, 2020-02-23 at 20:32 +0000, jdve...@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-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/PETKSMJ7SH2SN7VGXIRNQW4DTFUUKD2P/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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/3ZBCYQCJVYN6UEIG4UO7PBRMG4WBFU3B/ Code of Conduct: http://python.org/psf/codeofconduct/
