[Python-3000] Making more effective use of slice objects in Py3k

Nick Coghlan ncoghlan at gmail.com
Mon Aug 28 13:40:41 CEST 2006

Guido van Rossum wrote:
> On 8/27/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> I believe the current mixed model is actually an artifact of the 
>> transition
>> from simple slicing to extended slicing,
> Really? Extended slicing mostly meant adding a third "step" option to
> the slice syntax, which is useful for NumPy but completely pointless
> for string searches as we're discussing here. The slice() object was
> invented as an API hack so that we didn't have to add new special
> methods.

This is exactly what I'm talking about - I believe the reason you don't see it 
as an oddity, is because you were used to the "start+stop" idiom from before 
slice() was added. For me, only starting to seriously use Python after the 
__*slice__ family of methods had already been deprecated, slice() objects are 
the basic idiom, with any occurrences of "start+stop" being artifacts of the 
old slicing model.

For someone picking up the language after slice() has been added, it's like 
"we've gone to all the effort of defining a type just for sequence slices, but 
we're only going to use it in this one little corner of the language".

>> All other instances in the core and standard library which use a 
>> different
>> representation of a sequence slice (like the optional arguments to string
>> methods, or the result of the indices() method) would change to use 
>> one of
>> those two types. The methods of the types would be driven by the needs 
>> of the
>> standard library.
> What's the indices() method?

An existing method on slice objects that accepts a sequence length and returns 
the appropriate (start, stop, step) 3-tuple. Very handy for implementing 
__getitem__ methods properly.

> Write the PEP and make sure it is plentiful of examples of old and new
> ways of doing common string operations.



Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-3000 mailing list