[Python-3000] Removing __getslice__ et al.

[Nick Coghlan]

Thomas Wouters wrote:
> 
> A long-standing part of Py3K is removing 'old style slices' (meaning the 
> __get/set/delslice__ methods and the sq_slice/sq_ass_slice sequence-struct
> functions, but not slice objects.) I started removing them, only to find
> out that it's damned inconvenient to make all slicing go through
> tp_as_mapping->mp_subscript, for two reasons:
> 
> - Many classes don't behave as mapping at all, so the mp_subscript function
> (and the whole tp_as_mapping struct) would be added just for the benefit of
> accepting slices, which is really a sequence thing, not a mapping thing.

These types already provide tp_as_sequence->sq_item. Why would they want to
provide tp_as_mapping->mp_subscript as well?

> - There's actually a PyMapping_Check that relies on sq_slice: a type is a
> mapping type when it has tp_as_mapping->mp_subscript but not 
> tp_as_sequence->sq_slice. I'm not sure how to express that if there is no
> special method for slicing.

How about changing it to check tp_as_sequence->sq_item instead? (that will 
still work for dictionaries - they only define tp_as_sequence because there 
isn't a slot to hook "__contains__" in the tp_as_mapping structure)

On a slightly different note, we should fix the definition of sequence vs 
mapping so that PySequence_Check and PyMapping_Check work for arbitrary Python 
classes.

For example, a flag "__sequence__ = True" that type() checked when
constructing the class. If the flag was missing, both 
tp_as_mapping->mp_subscript and tp_as_sequence->sq_item would be filled in 
with __getitem__ (as they are now). If the flag was present and false, only 
tp_as_mapping would be filled in. If the flag was present and true, only 
tp_as_sequence would be filled in.

> (While on the subject, howmuch of the C API dealing with slices should be
> adjusted? There's PySequence_GetSlice() that takes Py_ssize_t's, which is
> (IMHO) pretty convenient for C code, but it'd have to create a slice object
> behind the scenes. And maybe creating a slice object manually isn't that
> much effort, after all.)

I think we should leave abstract.h alone - Getting rid of __getslice__ at the 
Python level is a good thing, but simply fixing these API functions to "do the 
right thing" is easier than breaking all the code that currently uses them.

Should we add a convenience function PySlice_FromIndices to the slice API that 
accepts Py_ssize_t's rather than PyObjects?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org