Dag Sverre Seljebotn wrote: > Stefan Behnel wrote: > >> Dag Sverre Seljebotn, 03.02.2010 10:22: >> >> >>> Me and Kurt's been talking about (finally) getting the memory views >>> merged. >>> >>> >> Could you add a sentence or two on what we are talking about here? We've >> had several discussions in the past regarding various kinds of memory views >> and array types. >> >> When it comes to arrays (which I interpret as "data container" -- what actually calls malloc/free), there is currently a utility class
cython.view.array which is rather stupid, it basically links together malloc and PEP 3118. These have to be explicitly instantiated, and can then be assigned to a memory view variable just like any other object. There's no special treatment of this in the compiler except that it is bundled into the same C file rather than being in a seperate module (Cython utility code) -- and even that could be changed if we want to have a "Cython standard library" at some point. Dag Sverre > These are the ones implemented by Kurt last summer, and which was > discussed in that painstakingly long discussion which ended with Robert > being pronounced BD. > > I.e.: > > cdef int[:,::1] arr = some_object # acquires C-contiguous PEP 3118 view > cdef int[:,::1] other = arr # refcounted assignment without requesting a > new view > > cdef func(int[:, ::1] arr): # takes an efficient custom Cython struct > pass > > and so on. Currently it only supports some automatic buffer copying > (Kurt can explain better exactly what) and direct access to underlying > buffer pointers and shape/strides, i.e. syntax candy. Obviously > efficient indexing should be added, which is relatively easy. > > I am aware that full documentation in the form of a CEP is somewhat > lacking (that is, things have shifted a bit since the CEPs were > written), but as it is, if I were to update the CEPs I wouldn't have > time to actually get this merged, and I'd really prefer to finish things > first, then document it. > > Rationale: Like I said last summer, my stance here is primarily "let's > reserve a corner of the syntax for the stuff numeric users/data pushers > need", and let things evolve out of what people actually use and request > and implement, not out of academic discussions on the mailing list. I > just don't have time for the latter. > > (Sorry for going into defensive position immediately, but the experience > from last summer still haunt me.) > > Dag Sverre > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev > _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
