[Python-3000] Removing 'old-style' ('simple') slices from Py3K.

[Thomas Wouters]

I spent my time at the Google sprint working on removing simple slices from
Py3k, in the p3yk-noslice branch. The work is pretty much done, except for
some minor details and finishing touches. There are a few items that should
probably be discussed, though.

The state of the tree:
 - The SLICE, STORE_SLICE and DELETE_SLICE opcodes (all 4 versions of each)
are eradicated. This even freed up a local (register) variable in
PyEval_EvalFrameex(), and probably resulted in a speedup of the bytecode
loop. I didn't measure it, though.
 - Various types that didn't support extended slicing had such support
added:
    - UserList, UserString, MutableUserString
    - structseq (what os.stat and time.localtime and such return)
    - sre_parse.SubPattern (well, more or less)
    - buffer
    - bytes
    - mmap.mmap
 - Various types that supported extended slicing now specialcase simple
slicing, for extra speed (list, string, unicode, array, tuple)
 - the ctypes 'Array' and 'Pointer' types support slicing with
slice-objects, but only with step = 1
 - The __getslice__, __setslice__ and __delslice__ slots aren't created
anymore, for C types.
 - The PySequence_GetSlice, PySequence_SetSlice and PySequence_DelSlice no
longer try to access the sq_slice and sq_ass_slice PySequenceMethods
members. They did already fall back to the mp_subscript and mp_ass_subscript
PyMappingMethods members.
 - All tests pass, with only the expected changes to any tests.
 - The PySequenceMethods struct's 'sq_slice' and 'sq_ass_slice' members are
unused and have been renamed
 - PyMapping_Check() now returns true for any type with a
PyMappingMethods.mp_subscript filled, not just those without a
PySequence.sq_slice. One test had to be adjusted for that -- execfile("",
{}, ()) now raises a different error, so it now tests execfile("", {}, 42)
 - There's no way to figure out the size of a Py_ssize_t from Python code,
now. test_support was using a simple-slice to figure it out. I'm not sure if
there's really a reason to do it -- I don't quite understand the use of it.
 - It's still lacking tests for the extended-slicing abilities of buffer,
mmap.mmap, structseq, UserList and UserString.

I think the extended-slicing support as well as the simpleslice
specialcasing should be ported to 2.6. Are there any objections to that? It
means, in some cases, a bit of code duplication, but it would make 's[::]'
almost as fast as 's[:]' for those types.

I also think it may be worthwhile to switch to always using slice objects in
Python 2.6 or 2.7. It would mean we can remove the 12 bytecodes for slicing,
plus the associated code in the main bytecode loop. We can still call
sq_slice/sq_ass_slice if step is None. The main issue is that it might be a
net slowdown for slicing (but speedup for all other operations), and that it
is no longer possible to see the difference between obj[:] and obj[::]. I
personally think code that treats those two (significantly) differently is
insane.

Now that all those types have mp_subscript defined, we could remove sq_item
and sq_ass_item as well. I'm not entirely sure I see all the implications of
that, though. The C code does quite a lot of indexing of tuples and lists,
and those are indexed using Py_ssize_t's directly. Going through a PyObject
for that may be too cumbersome.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060824/c60c127a/attachment.htm