Stefan Behnel wrote:
> 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.
I've been struggling to find the right terms for this the entire spring
-- perhaps the right term for CEP 517 is "typed memoryviews", although
which can allocate new memory when necesarry.
What I mean is that this doesn't make sense:
import numpy as np
...
data = np.memmap("ten_gigabytes.dat", dtype=np.double)
cdef double[:] access_to_data = data
access_to_data.append(3)
because access_to_data ultimately accesses memory "on disk" in a memory
mapped file, and we definitely can't append to file through PEP 3118.
> -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).
Yep, it wouldn't work, you need to do some_array[2:5].copy().
I'm really sorry about forgetting about this not being standard Python.
I think you are wrong in it being unprecedented: memoryview seems to
support similar behaviour (although I can't quite figure it out and
there's no docs on it?)
Just think of it as "slicing up the view", the data belonging to another
object... all int[:]s are really views.
All the 3rd party numeric libraries has been doing this for ages, which
I'd count as at least some "precedence".
BUT, this was one of the big reasons NumPy would never make it into core
Python IIRC.
> 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.
That would be too unwieldy:
x.slice((3, 4, 5), (1, 2, 3))[...] = 4
rather than
x[3:4:5, 1:2:3] = 4
> 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 fault is mine in not describing CEP 517. Efficient slices (and I
meant view-creating slices, though that wasn't written down
unfortunately) was a core motivating factor in CEP 517. If you copy then
slices can't really be efficient...
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
