[issue24243] behavior for finding an empty string is inconsistent with documentation

[Martin Panter]

Martin Panter added the comment:

There are a few related issues here I think:

1. Empty string search: I think it is completely valid to be able to find an empty string inside another string, at least as long as the slice indexes are within range. Although I remember it was a bit of a revelation the first time I considered this. Anyway, the documentation should explicitly mention this case.

2. "".find("", 1, 0) -> -1: This is inconsistent with startswith() and slicing, but the only reasonable alternative would be to return 1, which would be a strange index for an empty string. Certainly needs documenting though.

3. starts/endswith() slice arguments: I think they should be described equivalently to find() etc. So “start” points to the first character, “end” points after the last character, negative indexes from the end, etc.

4. "".startswith("", 1, 0): This is True for str, and False for bytes, which is terribly inconsistent. My gut says both should be False, to match how find() works.

Some other related undocumented quirks:

>>> "abcd".count("")  # Infinity? End of the universe? No!
5
>>> "abcd".replace("", "_", 10)  # Might expect 10 underscores
'_a_b_c_d_'
>>> "abcd".split("", 10)  # Might expect a list of 11 strings
ValueError: empty separator
>>> "abcd".partition("")  # Why not ("", "", "abcd")?
ValueError: empty separator

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24243>
_______________________________________