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

R. David Murray added the comment: I'm not Raymond, but he is correct. This is an example of "taking advantage of the corner cases", and is something Python does a lot of, especially around strings and slices. The current behavior was carefully considered and has useful properties.

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

Antoine Pitrou added the comment: I'm not sure why we're arguing over this. Is this actually something that matters in the real world? -- ___ Python tracker

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

Vedran Čačić added the comment: Raymond, with respect, I think you're either wrong here, or misleading with a purpose. There is a big difference between any(()) returning False, all(()) returning True, '' in '' returning True, math.factorial(0) returning 1, and set() <= set() returning

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

Serhiy Storchaka added the comment: Opened separate issue24284 for inconsistency in startswith/endswith. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24243 ___

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

swanson added the comment: Thanks for pointing out how count and replace operate. I don't mind the ValueError: empty separator on split and partition - makes sense to me. re: at least as long as the slice indexes are within range If the slices indexes had to be in range, that would be

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

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

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

Serhiy Storchaka added the comment: Changing behavior of such base methods is dangerous and can break existing code. Even if the behavior is wrong, some code can depends on it. We should be very careful with this. There are several simple invariants for these methods. s1.index(s2, start,

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

R. David Murray added the comment: Serhiy: I agree. I think the consistency with python2's string is the deciding factor, and we ought to fix it in default. But not 3.4, because it is a behavior change. I'd like other people's opinions, though. --

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

R. David Murray added the comment: 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

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

Raymond Hettinger added the comment: Changing behavior of such base methods is dangerous and can break existing code. I agree. The time to argue an API design is before it released not years later after people have written code that relies on the behavior. To me, semantically, the

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

R. David Murray added the comment: Raymond: this is currently marked as a documentation bug, and documentation is mostly what the OP was asking for. So I'm reopening it. That said, I think it is very appropriate to discuss fixing the behavior of string's endswith and startswith, because

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

New submission from swanson: Background: --- Perhaps this has been addressed elsewhere, but I couldn't find it. To me, semantically, the whole idea of finding nothing, whether in something or in nothing is complete and utter nonsense. I'm a fail-quickly, fail-loudly kind of guy, and