Do slices really must have step size of 1? about btrees HOT 1 OPEN

In the C extension, slices are implemented by just returning a new Items object, just like a plain call to keys():

>>> a.keys()
<OOBTreeItems at 0x11084fc40>
>>> a.keys()[1:2]
<OOBTreeItems at 0x10fcc2ee0>

That object uses the same underlying bucket storage as the tree, and it doesn't have any place to store the extra state needed to track a different step size, so that's the first problem.

More serious, though, is that BTreeItems support indexed subscripting of themselves:

>>> bt = OOBTree()
>>> bt['a'] = 1
>>> bt.keys()[0]
'a'

They implement iteration using that subscripting support through the old iteration protocol. So the object would have to be changed to understand how to compute "real" indexes based on a different step size, which sounds like it could get ugly.

I'll note that the Python implementation just punts the whole problem over to list for any slice:

>>> from BTrees.OOBTree import OOBTreePy
>>> a = OOBTreePy({1:"one", 2:"two", 3:"three"})
>>> a.keys()
<BTrees._base._TreeItems object at 0x1026fb858>
>>> a.keys()[1:2]
[2]

That loads the whole tree into memory, though, which is not efficient. But it works (for small cases...) and probably wouldn't be that hard to adopt in C if we wanted to. (Either that or the Python implementation should enforce the same restriction.)

from btrees.