Dag Sverre Seljebotn, 25.10.2009 21:26: > Stefan Behnel wrote: >> This would be a rather straight forward thing to support: >> >> cdef char* s = ... >> py_s = s[:30] >> >> It would translate directly to a call to PyString_FromStringAndSize(), >> which is a rather often requested feature IMO. All other base types would >> return a runtime-constructed list instead: >> >> cdef int* x = ... >> py_int_list = x[4:20:-1] >> >> This would generate a loop that creates Python int values from the slice >> and put them into a list, so it's basically a short form for this: >> >> py_int_list = [ int(x[i]) for i from 20 >= i > 4 by -1 ] > > After a little more thinking here's another perspective: > > a) I support turning charptr[:length] into bytes w/ explicit length, > because I feel that's something Cython should be able to handle more > gracefully.
Here we go: http://trac.cython.org/cython_trac/ticket/436 http://hg.cython.org/cython-devel/rev/57fa28d3b2e2 Note that this only supports "char*.decode()" for now, the other cases can be added later, i.e. the mapping to PyString_FromStringAndSize(), and the for-in loop support (which should actually be independent of the base type). > b) However I'm really doubting the extension to other types than char*. > It's going to be a different case (bytes and a list or array or memoryview > are very different types), and: Python is not Perl!! That is: The Python > philosophy has always been that a few characters extra to express > something is preferable to having too many concepts to learn in the > language. > > I feel intptr[a:b:c] contradict this: It is a feature which it probably > takes longer to learn about than to write the perfectly good list > comprehension manually, and Python is well known to not add syntax candy > in such cases. Therefore I don't think Cython should either. I don't quite buy that argument. When coercing to a Python object, a list sounds perfectly reasonable to me. But let's rediscuss this later, when we have a SIMD type, and when we see if it makes sense to use it for this use case also, or if other means seem more appropriate. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
