| msg51567 - (view) |
Author: Thomas Wouters (twouters) *  |
Date: 2006-12-18 04:28 |
| Support for slicing ctypes' Pointer and Array types with slice objects, although only for step=1 case. (Backported from p3yk-noslice branch.) |
|
|
| msg51568 - (view) |
Author: Thomas Heller (theller) * |
Date: 2006-12-20 18:45 |
| Unfortunately I'm unable to review or work on this patch *this year*. I will definitely take a look in January. Sorry. |
|
|
| msg51569 - (view) |
Author: Thomas Heller (theller) * |
Date: 2007-01-12 20:48 |
| Thomas, a question: Since steps != 1 are not supported, does this patch have any value? IIUC, array[x:y] returns exactly the same as array[x:y:1] for all x and y values. Formally, the patch is missing unittests and documentation ;-). |
|
|
| msg51570 - (view) |
Author: Thomas Wouters (twouters) * |
Date: 2007-01-15 11:48 |
| The point is that simple slicing will go away, and extended slices (with sliceobjects) are used in various places, and currently can't be passed on to ctypes arrays and pointers. That is to say, a Python class defining __getitem__ but not __getslice__ still supports slice syntax, but it can't do 'pointer[sliceobj]' -- it would have to do 'pointer[sliceobj.start:sliceobj.end]'. Also, because simple slices will go away, this code will have to be added to the p3yk branch in any case; having it in the trunk just makes for easier maintenance. Oh, and the non-support for steps other than 1 is not a fundamental issue, I just couldn't bear to write the code for that if you didn't think it would be useful, as I'd already written the same logic and arithmetic for array, tupleseq, mmap and I forget what else :P You can consider this code half-done, if you wish; I'll get to it again soon enough. |
|
|
| msg51571 - (view) |
Author: Thomas Wouters (twouters) * |
Date: 2007-07-12 07:54 |
| Thomas, do you consider non-step-1 slicing important? I'd really like to get the noslice branch merged into p3yk soon-ish, and I need to know which bits I need to commit to the trunk first (to avoid merge conflicts for the rest of the lifetime of the 2.x codebase.) |
|
|
| msg51572 - (view) |
Author: Thomas Heller (theller) * |
Date: 2007-07-12 10:17 |
| I think that full slicing support for pointers/arrays would be great. Presonally I have a use case for step = -1, in other words, I need to iterate backwards over a ctypes array. |
|
|
| msg55374 - (view) |
Author: Thomas Wouters (twouters) * |
Date: 2007-08-28 15:37 |
| I'd like to check this into the trunk, without the non-step-1 support for now, so that we can remove simple slicing from the py3k branch. We can always add non-step-1 support later (all the sooner if someone who isn't me volunteers to do the painful bits of that support, probably by copy-pasting from the array module ;-) |
|
|
| msg55419 - (view) |
Author: Thomas Wouters (twouters) * |
Date: 2007-08-29 13:43 |
| Added tests (by duplicating any slicing operations in the test suite with extended slice syntax, to force the use of slice-objects ;) |
|
|
| msg55442 - (view) |
Author: Thomas Wouters (twouters) * |
Date: 2007-08-29 21:26 |
| Implemented actual extended slicing support for the Array and Pointer types. The semantics of negative and ommitted indices in the Pointer case are somewhat muddy, but I took the approach the simple slicing code took: pretend the programmer knows what they're doing, and that the 'sequence' that is the pointer is actually PY_SSIZE_T_MAX elements long. I'm not sure I like that approach at all, but the actual problem is the unbounded nature of the pointers, and this is the only approach I can think of that makes sense, short of completely disallowing negative or missing indices. This patch is pretty much done now, I think. Note that it's entirely backward compatible, the incompatible bits (removing simple slicing) happen in Py3K. |
|
|
| msg55497 - (view) |
Author: Thomas Heller (theller) * |
Date: 2007-08-30 18:15 |
| Set to accepted. As pointed out in private email, please apply it to the trunk. Your thoughts about the 'length' of pointers make sense, and are very similar to what I had in mind when I implemented pointer indexing. For indexing pointers, negative indices (in the C sense, not the usual Python sense) absolutely are needed, IMO. For slicing, missing indices do not really have a meaning - would it be possible to disallow them? |
|
|
| msg55506 - (view) |
Author: Thomas Wouters (twouters) * |
Date: 2007-08-30 20:10 |
| Well, that's not quite how I implemented the slicing, and it's also not how the existing simple-slicing was implemented: A negative start index is taken to mean 0, and a stop index below the start index is taken to mean 'the start index' (leading to an empty slice.) However, it isn't too hard to do what I think you want done: a negative index means indexing before the pointer, not from the end of the pointer, and missing indices are only okay if they clearly mean '0' ('start' when step > 0, 'stop' when step < 0.) So: P[5:10] would slice from P[5] up to but not including P[10], P[-5:5] would slice from P[-5] up to but not including P[5], P[:5] would slice from P[0] up to but not including P[5], P[5::-1] would slice from P[5] down to *and including* P[0] but the following would all be errors: P[5:] P[:5:-1] P[:] P[::-1] Does that sound like what you wanted? |
|
|
| msg55507 - (view) |
Author: Thomas Heller (theller) * |
Date: 2007-08-30 20:19 |
| Yes. But looking at your examples I think it would be better to forbid missing indices completely instead of allowing them only where they clearly mean 0. Writing (and reading!) a 0 is faster than thinking about if a missing index is allowed or what it means. |
|
|
| msg55510 - (view) |
Author: Thomas Wouters (twouters) * |
Date: 2007-08-30 20:36 |
| Hmmm.... Well, that's fine by me, but it changes current behaviour, and in a way that ctypes own testsuite was testing, even ;) (it does, e.g., 'p[:4]' in a couple of places.) Requiring the start always would possibly break a lot of code. We could make only the start (and step) optional, and the start only if the step is positive, perhaps? That would change no existing, sane behaviour. |
|
|
| msg55518 - (view) |
Author: Thomas Wouters (twouters) * |
Date: 2007-08-30 23:49 |
| Checked in a slightly newer version. |
|
|