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.