On Sun, Oct 27, 2019 at 12:10:22AM -0700, Andrew Barnert via Python-ideas wrote:
> If you redesign your find, re.search, etc. APIs to not return
> character indexes, then I think you can get away with not having
> character-indexable strings.
If string.index(c) doesn't return the index of c in string, then what
does it return?
I think you are conflating the public API based on characters (to be
precise: code points) for some underlying implementation based on bytes.
Given zero-based indexing, and the string:
"abÇÐεф"
the index of "ф" better damn well be 5 rather than 8 (UTF-8), 10
(UTF-16) or 20 (UTF-32) or I'll be knocking on the API designer's door
with a pitchfork and a flaming torch *wink*
And returning <AbstractIndex object at 0xb7ce1bf0> is even worse.
Strings might not be implemented as an array of characters. They could
be a rope, a linked list, a piece table, a gap buffer, or something
else. The public API which operates on code points should not depend on
the implementation. Regardless of how your string is implemented, it is
conceptually a sequential array of N code points indexed from 0 to N-1.
--
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/YESU3G7CRBNTO43ULYCC652KTI4YVLBF/
Code of Conduct: http://python.org/psf/codeofconduct/
