You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#31312 is a fix for chop that seems to be hiding a deeper problem, namely that nextind("", 1, 0) should probably work instead of throwing an error. In general, when the number of characters to move is zero, I believe that any 0 ≤ i ≤ ncodeunits(s)+1 should be allowed in order to agree with thisind. When n > 0 then it makes sense to require 0 ≤ i < ncodeunits(s)+1. Motivation: well, the code that #31312 fixes is a perfect example. Similarly, prevind("", 0, 0) should also work.
If we mentally agree that 0 and ncodeunits(s)+1 are "would be" valid indices then this is consistent.
As the design for n=0 assumed that you can call it using a valid index only and will get a valid index in return. I do not see the risk when it would hurt to extend the definition the way you propose.
When this is fixed in the docstring s should be replaced by str both in prevind and nextind (wrong variable name was used in 3 places).
#31312 is a fix for
chop
that seems to be hiding a deeper problem, namely thatnextind("", 1, 0)
should probably work instead of throwing an error. In general, when the number of characters to move is zero, I believe that any0 ≤ i ≤ ncodeunits(s)+1
should be allowed in order to agree withthisind
. Whenn > 0
then it makes sense to require0 ≤ i < ncodeunits(s)+1
. Motivation: well, the code that #31312 fixes is a perfect example. Similarly,prevind("", 0, 0)
should also work.cc @bkamins
The text was updated successfully, but these errors were encountered: