[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