"abcde".rindex("") returns 5
"a".rindex("") returns 1 

This is not documented anywhere in the Python documentation.

Also, "".rindex("") returns 0

string.find() also exhibits the same behaviour.

"abcde".find("") -> 5 which also is not documented anywhere.

This is documented.

"Return the highest index in the string where substring sub is found,"

The documentation (https://docs.python.org/3/library/stdtypes.html#str.find) does not describe what will be the behaviour if the substring is "". 

And by the way, as per https://docs.python.org/3/reference/expressions.html#membership-test-operations, 

    Empty strings are always considered to be a substring of any other 
    string, so "" in "abc" will return True.

Returning an invalid index value, although confusing, should at least be documented in some form.

The behaviour for searching for empty strings in Python is inconsistent; see Issue 24243. IMO the behaviour for the (r)find/index methods is sensible, but it is worth making the documentation explicit.

The returned indexes you have given (5, 1, and 0) are valid for slicing.

The documentation doesn't mention empty string specially because there is nothing special with empty string.

Returned index value is valid. "abcde"[5:5] == "".

Issue24243 is about the case of end < start. Not this case.

I don't see a bug here.

I am not saying that there is a bug. As Martin points out, "it is worth making the documentation explicit."

How about 

"abcde"[5]
Traceback (most recent call last):
  File "python", line 1, in <module>
IndexError: string index out of range

5 is not valid index of character, but it is valid index of substring.

IMHO documenting explicitly miscellaneous particular cases which are not exceptions of general rules just adds a noise. This makes the documentation larger and decrease the chance that it will be read.

Look at my suggested changes. It doesn't add noise, IMHO.

All I am saying is that the explicit behaviour needs to be documented. 
I unnecessarily wasted at least 3-4 hours on this "undocumented" behavior.

@Storchaka, 

You say `5` is related to the substring. Pray, explain how 5 is related to a null substring? Also, from https://bugs.python.org/msg243710, as per the great Hettinger:

   Though this is closed as not a bug, feel free to add an example or a 
   mention in the documentation.  Keep it short though.  

That's all I am asking to be included.

This is nonsense. 'abcde'[7:7] is also ''. So the maximal index in fact doesn't exist. What do you think exactly is the property that differentiates 5 from 7 here?

You have to remember that the most useful way to think about python slice indexes is that they point between characters. Consider, for example, that you have a starting index of something, and you are looking backward in the string for a trailing delimiter:

  >>> x = 'this is <weird example> of something'
  >>> x.rfind('>', 9)
  22
  >>> x[9:22]
  'weird example'

So the above is why 5 is different from 7: 5 is the index that you would use in a slice if you wanted the string that ended before the match...and the match in the null string case is the end of the string.  That is, Python is being consistent in this degenerate case.

Maybe you would use 5, but I would use 7 and get the same result. If the docs say "X.rindex(Y) == i means i is the highest index where Y is found in X", and "Y is found in X at i" is interpreted as "X[i:i+len(Y)] == Y" (as Serhiy said), then there is no such (highest) index.

I understand what _you_'re saying, but please understand that the docs do not say anything like that.