[Patches] [Patch #101029] Call __getitem__ for slices when no __getslice__

[noreply@sourceforge.net]

Patch #101029 has been updated. 

Project: 
Category: core (C code)
Status: Accepted
Summary: Call __getitem__ for slices when no __getslice__

Follow-Ups:

Date: 2000-Jul-31 15:55
By: twouters

Comment:
Call __getitem__ if no __getslice__ is available. similar for __delslice__ and __setslice__, and for the C API: calls mp_subscript() with a slice object of (start, end, None) if there is no sq_slice(), and the same for sq_ass_slice().

Eventually the reverse should be done, too: call __getslice__ instead of __getitem__ if the object has a __getslice__, and the 3rd argument to the slice is None: That way, we can ditch the 12 silly SLICE* opcodes, and always use slice objects. This *will* result in x[::] being passed to __getslice__ (if available) instead of __getitem__, however, so it is not 100% backwards compatible.

This patch is not terribly tested: I'm not feeling well, and I want to post this patch before I head off to home and dive back in bed ;) It doesn't crash, it survives 'make test', it survives manual testing, but it might leak.


-------------------------------------------------------

Date: 2000-Jul-31 16:55
By: gvanrossum

Comment:
Looks cool to me, except that there's a lot of code duplication.

Maybe you can add a static helper routine to create a slice out of two ints to abstract.c and one that creates a 1-tuple containing such a slice to classobject.c.  (Trying to share code across .c files would require turning it into an official API which I think is overkill.)
-------------------------------------------------------

Date: 2000-Jul-31 23:35
By: twouters

Comment:
New version with less code duplication. Less, not none, unfortunately, because both abstract.c and classobject.c need roughly the same function :P Making the classobject.c one return a 1-tuple is not very useful, because only one place needs a 1-tuple, the other needs a 2-tuple, and I don't fancy modifying the 1-tuple separately.

Don't you wish C was more like Python ? *sigh*

-------------------------------------------------------

Date: 2000-Aug-15 20:56
By: tim_one

Comment:
Assigned to Guido because his is the next natural voice in the conversation.

Thomas, note that this needs doc and test patches too if it's not to be Postponed.
-------------------------------------------------------

Date: 2000-Aug-16 01:00
By: twouters

Comment:
Just to show y'all that I *can* write documentation and test cases, I've included both in this patch. In fact, those parts take up a lot more space than the actual code change, now ;) Mostly because the test case also tests all other Python class __hooks__. I couldn't find the testcase for them, so I wrote one.

The doc changes definately need an editor, if only to add some cross references to slice objects and such. Also, depending on the BDFL, some stronger language might be in order, to scare people away from __getslice__ and brothers.

-------------------------------------------------------

Date: 2000-Aug-17 21:18
By: gvanrossum

Comment:
I believe I came up with this myself, and I still like the idea.  Was there any debate about this?  (I'm hopelessly behind on python-dev mail.)
-------------------------------------------------------

Date: 2000-Aug-17 22:10
By: twouters

Comment:
Yes, there was a debate, mostly between you, me, Michael Hudson and the occasional post by others. The thread is an old one, nothing has been said about this recently. The thread started as '[Python-Dev] PEP 203 Augmented Assignment', but quickly split  into three separate discussions: one about why we have __getslice__ at all, one about reordering opcodes, and another about extended slicing on builtin types, which prompted Michael to submit a patch that adds extended slicing to builtin lists. 

In general, you seemed to think the current split between extended slices and basic slices should be solved by using slice objects for basic slices too. You briefly argued for a backwards-compatible way of passing simple-extended slice objects to __getslice__, but that was a think-o, I think :)

The start of the thread can be found here:

http://www.python.org/pipermail/python-dev/2000-July/014071.html

A handful of the messages ended up in August, too, but mostly not on this particular issue.

I'll review this patch for the last time tonight, and then check it in.

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101029&group_id=5470