Xrange() and Slice() have evolved to be very similar.  
Merging the code for xrange() into slice() will 
complete the transformation, put all the capability 
into one object, eliminate an object type, eliminate 
two source files, and shrink the Python concept 
space by a modest amount.

Discussion on py-dev (see thread Xrange and Slices 
starting on 6/26/2002) was generally favorable. All 
of the design suggestions received have been 
incorporated in this patch.

Slice is left intact as a mutable container of arbitrary 
Python objects.  It's sq_item, sq_len, and tp_iter slots 
are filled in to give it the same sequence behavior as 
xrange().  The tp_iter slot creates an immutable 
iterator based on the state of the slice at the time the 
iterator is created.  The iterator uses c longs instead 
of PyObjects to protect its immutability and to keep 
the super fast speed that it had in xrange().

To keep the old xrange iterface intact, 'xrange' is 
made synonymous with 'slice'.  Also, slice.h is given 
macros and a PyRange_New() wrapper so that the 
xrange C API is left intact.

Two minor open issues:
1. Should repr() say 'slice' or 'xrange'?
2. What should the return value be for slice_length() 
when step is zero or None?

Patch passes all regression tests.  A news item 
should be added eventhough the APIs are unchanged.

Logged In: YES 
user_id=80475

New patch attached. Incorporates three ideas from Oren 
Tirosh's code review (int-->long, xrange as public interface, 
return -1 on len error).

I'm away from the computer for the next five weeks. Oren 
has agreed to champion my patches (not necessarily 
advocate, just make sure they get a fair trial and that 
requested changes get made).

Logged In: YES 
user_id=6380

Rejecting. It's better to let these two be different, so
that it's clear what the intended use is.