<br>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.
<br><br>The state of the tree:<br>&nbsp;- 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.
<br>&nbsp;- Various types that didn't support extended slicing had such support added:<br>&nbsp;&nbsp;&nbsp; - UserList, UserString, MutableUserString<br>&nbsp;&nbsp;&nbsp; - structseq (what os.stat and time.localtime and such return)<br>&nbsp;&nbsp;&nbsp; - sre_parse.SubPattern (well, more or less)
<br>&nbsp;&nbsp;&nbsp; - buffer<br>&nbsp;&nbsp;&nbsp; - bytes<br>&nbsp;&nbsp;&nbsp; - mmap.mmap<br>&nbsp;- Various types that supported extended slicing now specialcase simple slicing, for extra speed (list, string, unicode, array, tuple)<br>&nbsp;- the ctypes 'Array' and 'Pointer' types support slicing with slice-objects, but only with step = 1
<br>&nbsp;- The __getslice__, __setslice__ and __delslice__ slots aren't created anymore, for C types.<br>&nbsp;- 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.
<br>&nbsp;- All tests pass, with only the expected changes to any tests.<br clear="all">&nbsp;- The PySequenceMethods struct's 'sq_slice' and 'sq_ass_slice' members are unused and have been renamed<br>&nbsp;- 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(&quot;&quot;, {}, ()) now raises a different error, so it now tests execfile(&quot;&quot;, {}, 42)
<br>&nbsp;- 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.
<br>&nbsp;- It's still lacking tests for the extended-slicing abilities of buffer, mmap.mmap, structseq, UserList and UserString.<br><br>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.<br><br>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.
<br><br>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.
<br><br>-- <br>Thomas Wouters &lt;<a href="mailto:thomas@python.org">thomas@python.org</a>&gt;<br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!