Hi,
Dag Sverre Seljebotn wrote:
> Stefan Behnel wrote:
>> I also read in CEP 517 that resizing is not to be supported. Why not? It
>> could just fail with an exception when it notices that there are live
>> buffers on it.
>
> It just seemed kind of useless if only Cython-allocated memory can be
> resized, and not C arrays or memory in other Python objects. But we
> could do it for Cython-allocated memory, perhaps by extending PEP 3118
> with some Cython-specific flags etc.
I don't understand what resizing has to do with PEP 3118 at all. You
obviously wouldn't resize a buffer view but the memory object itself. The
only link is that resizing would fail if you reduced the size of a memory
object while there is a live buffer view on it.
>>> 3) Accessing Py_buffer directly is too inefficient, so it must be
>>> unpacked in to a custom struct on the stack which basically holds
>>> shape/stride information and a reference to the Py_buffer-holding thing
>>> in 2). This is the actual variable/temporary type, and is passed-by-value.
>>>
>>> When taking a slice, the struct in 3) is copied (while adjusting the
>>> shape/strides), increfing the view 2) in the process, and 2) holds on to 1).
>> So a slice would be a view? Because if it was a copy, you'd need a separate
>> memory object to back it. A view would be easiest handled by the normal
>> memoryview(), though, right? And I find a copy much less surprising...
>
> Sorry, another NumPy-ism which I forgot wasn't there in core Python.
> I'll fix the CEP at some point. Yes, slices are views and absolutely
> have to be. Slices being natural and efficient views to work with is
> kind of one of the main points.
-1 on slices returning views for a sequence type. That is completely
unprecedented in Python and would only lead to confusing and buggy code.
What would you do to get a 'real' slice copy then? Requiring a user to do
some_array[2:5][:]
looks totally wrong to me (besides not even working if the second slice
returned a view, too).
This *may* make more sense for a SIMD type, but even there I suggest not
using the slicing syntax for this. Make it a method call that returns a
slice view.
I get the impression by now that CEP 517 and CEP 518 are not related. They
describe completely different types, but only the array type makes sense in
the context of Cython. The SIMD type would introduce semantics that exist
neither in Python nor in C.
The only problem is that a SIMD data type requires Cython compiler support,
otherwise, you could just go and implement it as an external type. If you
see any way to implement this as an add-on rather than a compiler feature,
you'll have my blessing immediately. But I do not see this becoming a
smooth part of the language.
Yes, I'm being NIMCy here, but I really don't see this fit into the
language, sorry. I don't like dark corners in a programming language that
"you don't have to care about because you are not an XYZ user". That's ok
for a stdlib, but not for a language.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
