[Python-Dev] non-integer arguments to simple slices in 1.6?

Guido van Rossum guido@beopen.com
Mon, 10 Jul 2000 08:29:41 -0500


I got the following email from Scott Johnston which suggests an
interesting idea (for 2.0, of course, as that's what we're all working
on now).  basically, Scott proposes to deprecate __getslice__ (and its
friends, __setslice__ and __delslice__) in favor of passing the slice
arguments unadorned to __getitem__  if __getslice__ is not defined.

On the surface, this seems reasonable to me, except that it doesn't
help for extension classes...

Any other comments?

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)

------- Forwarded Message (reformatted)

Date:    Mon, 10 Jul 2000 00:03:07 -0700
From:    "Scott F. Johnston" <scott@fleetingimage.com>
To:      guido@python.org
Subject: non-integer arguments to simple slices in 1.6?

For python 1.6/2.0, have you considered unifying the slice operations?

I'd like to be able to use simple "[:]" slice syntax on a class using
non-integer indices, and without having negative indices automatically
"wrapped".

I can do this with the complex slice "[::]" syntax, but adding the
extra colon and having two different slicing methods seems
inconsistent. (One trapped in __getitem__ receiving unmutated objects
in a slice object, the other in __getslice__ receiving mutated ints
only.)

There is an easy way of unifying this:

 Allow single-colon slices to be passed unmutated to a __getitem__
 method as a slice object IF AND ONLY IF the class doesn't provide a
 __getslice__ method.  (And allow the args to be any object as in the
 current [::] syntax.)

Currently, trying to slice an object without a getslice method raises
an error. If my __getitem__ handler is set to handle a [::] slice, why
not let it handle [:] slices as well?

This would be a good way of slowly depricating the __*slice__
operations.

Optimally, I shouldn't have to test for SliceType in my __*item__
methods, and all slices would go unmutated to __*slice__ with an
additional step term, but that would break a lot of legacy code.

Thanks,

- --S

------- End of Forwarded Message