The attached test shows many cases where 
string.startswith() and string.endswith() fail to 
handle negative slice indices correctly.  The failures 
are in both the start and end indices.  I stumbled 
into this when tracking down why (what turned out to 
be) this didn't work:

>>> file = 'difflib.pyc'
>>> file.endswith('.py', 0, -1) # should be 1
0
>>> file[0:-1].endswith('.py')  # like this is
1
>>>

Can we risk changing this for 2.2?  Don't know.  If 
not, reduce the priority.

Logged In: YES 
user_id=31435

Attached the test case.

Logged In: YES 
user_id=6380

Hm, the docs don't exactly suggest that negative indices
would be supported. While that would be nice, it's
definitely a feature request, so no, please don't do this in
2.2. (The absent of unit tests for negative indices also
suggests this was not an oversight. :-)

Logged In: YES 
user_id=31435

I can't guess what the docs intended to say (they're vague -
- I can read them several ways).

In all other cases where optional string-method args 
named "start" and "end" are accepted (find(), rfind(), count
(), index(), rindex()), the docs are clear that they're 
interpreted as slice notation.  It doesn't make sense for 
the two newest methods to behave differently in this 
respect.

The unit tests aren't evidence one way or the other to me --
 the behavior of negative indices should be covered by the 
tests no matter what the intended semantics.

Overall, I expect the behavior here is an accident (as 
opposed to intended).

Logged In: YES 
user_id=12800

The comment in the code reminds me that we adopted the
semantics for Java's String.startsWith() and String.endsWith(): 

http://java.sun.com/products/jdk/1.2/docs/api/java/lang/String.html#startsWith(java.lang.String,%20int)

which treats negative indices as errors (at least for the
start parameter -- which we generalized to include the end
parameter).  Changing this is a semantic change to the
string methods, so I don't think it should be undertaken
lightly (i.e. as a bug in the current implementation).

Logged In: YES 
user_id=6380

We should fix this in 2.3 at the very least. Leave 2.2.x
alone.

Logged In: YES 
user_id=33168

Attached is a patch which implements this behaviour.
Still need a patch for tests and the doc.
This passes all regressions and Tim's test.

Logged In: YES 
user_id=6380

Check in in, Neal. (Barry is too busy to watch SF.)

Would you mind adding unit tests?

Logged In: YES 
user_id=33168

I'll update the tests & doc before checking in.

Logged In: YES 
user_id=33168

Checked in as:
  Doc/whatsnew/whatsnew23.tex 1.25
  Lib/test/string_tests.py 1.18
  Objects/stringobject.c 2.168
  Misc/NEWS 1.427