[Python-3000] Making more effective use of slice objects in Py3k
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
>> 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
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
>> 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