This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients docs@python, martin.panter, r.david.murray, swanson
Date 2015-05-20.14:00:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1432130455.39.0.291181134884.issue24243@psf.upfronthosting.co.za>
In-reply-to
Content
"If the slices indexes had to be in range, that would be inconsistent with the behavior of slicing"

No, it wouldn't.  Your slice example is two operations: the slice returns an empty string (because that's how the *substring* operation is defined to behave for an out-of-range slice), and *then* the search operation is called on it; but in the call with index arguments, the indicies are specifying the slice to search in using the slice semantics of the indicies, but that substring is invalid for the *search* operation.

I agree that the startswith/endswith difference between string a bytes looks like a bug, and that the bytes case looks to be the correct one, in terms of consistency with the other search operations.  Those operations are a bit different from the other search operations, though, so I could see it argued the other way.

The point is that the slice notation specifies how to compute the substring, but what happens if the substring is out of range depends on the *operation*.
History
Date User Action Args
2015-05-20 14:00:55r.david.murraysetrecipients: + r.david.murray, docs@python, martin.panter, swanson
2015-05-20 14:00:55r.david.murraysetmessageid: <1432130455.39.0.291181134884.issue24243@psf.upfronthosting.co.za>
2015-05-20 14:00:55r.david.murraylinkissue24243 messages
2015-05-20 14:00:54r.david.murraycreate