Note 5 (at <https://docs.python.org/2/library/stdtypes.html#sequence-types-str-unicode-list-tuple-bytearray-buffer-xrange> for Python 2 and at <https://docs.python.org/3/library/stdtypes.html#common-sequence-operations> for Python 3) concerning s[i:j:k] (the slice of s from i to j with step k) contains the following two sentences:

"The slice of s from i to j with step k is defined as the sequence of items with index x = i + n*k such that 0 <= n < (j-i)/k. In other words, the indices are i, i+k, i+2*k, i+3*k and so on, stopping when j is reached (but never including j)."

That limit, "(j-i)/k" is demonstrably wrong when the integer division has a non-zero remainder.  For example, for i=0, j=3, and k=2, n must be less than int(3/2) = 1 (i.e., the slice only has one element) according to that limit, but in fact the slice has two elements in agreement with the second sentence and which can be seen from the following python (2 or 3) code example:

>>> x = [0,1,2,3,4,5]
>>> x[0:3:2]
[0, 2]

The following Python result is also instructive for negative steps.

>>> y=[5,4,3,2,1,0]
>>> y[-1:-4:-2]
[0, 2]

For this case as well the result is consistent with the second sentence of the documentation but inconsistent with the first sentence since according to that limit = int((len-4 - (len-1))/-2) = int(3/2) = 1 implying only one element in the slice in contradiction to the above result.

Therefore, I suggest removing the incorrect mathematical limit "(j-i)/k" from note 5 by replacing the above two sentences as follows:

"The slice of s from i to j with positive or negative step k is defined as the sequence of items with index x = i + n*k such that the indices are i, i+k, i+2*k, i+3*k and so on, stopping when j is reached (but never including j)."

Alternatively, one could replace the current incorrect limit by the correct mathmatical expression.  My guess is the limit should be "(j-i)/k" when there is a zero remainder for that division, and "(j-i)/k + 1" when there is a non-zero remainder.  That limit works for the above two examples, but I don't know how to prove that in general for this integer limit case.  Furthermore, even if somebody else can provide that proof, I still think the above single sentence documents the slice limits exactly, is simpler, and therefore is preferred.

N.B. I am formally reporting this issue as a Python 3 bug but as shown above the same two sentences occur in the Python 2 documentation so when this bug is fixed for the Python 3 documentation it should also be consistently fixed for Python 2.

My guess is that the formula is not using integer division.  There are two elements, n=0, and n=1.  1 is less than 1.5.  In python2 it would be a natural assumption that that formula was referring to python2 division, and that should be clarified if I'm right.

You can easily prove the limit is correct for real numbers.  So I would be willing to accept as a resolution of this issue that the type of division that is going on here is real.  However, that is a bit disquieting since if you try a real slice index you get "TypeError: slice indices must be integers or None or have an __index__ method". Thus, m < real limit test is a comparison of an integer and real which implies m gets changed to real before the comparison. Which obviously gives the correct result in the 1.5 case, but in general I dislike real comparisons where the distinction between < and <=, for example, can get blurred because of potential roundoff issues with reals.  So I think my suggested one-sentence resolution to the issue is better then updating the documentation to clarify what kind of division is occurring in the limit.

The formula is documenting the behavior, not the implementation.  So the formula is a mathematical formula that assumes infinite precision, not a floating point calculation.  I always thought that was clear by context and phrasing, but perhaps I'm wrong.

n < (j-i)/k is a straightforward translation of i + n*k < j, and vice verse, where / is rational division.  It is incorrect to integerize the result and the doc does not say to do so.  In Python 3, there is no ambiguity, and the doc is *not* incorrect, and does not need to be changed.  In Python 2, I think it still clear enough, but we could add "(where / indicates rational division)'.  However, I also think this might be too nitpicky.  I am inclined to think that this should be closed.

>  I am inclined to think that this should be closed.

I concur.

The problem with the nitpick and word-smithing is that over-explaining tends to make the docs harder to read and understand by getting in the way of the basic message.

Given that this passage has worked well enough for users for a very long time, it is likely best to leave in alone.