On Wed, Feb 3, 2010 at 3:22 AM, Dag Sverre Seljebotn <[email protected]> wrote: > Me and Kurt's been talking about (finally) getting the memory views > merged. Initially I held back because I wanted to do my part of the job > first (support indexing, currently they only support raw buffer access > and copying), but in the light of how long that's been taking me it's > better to get things merged now -- especially as Kurt has a use for the > existing functionality in fwrap. > > Question first: > - Should the memoryview namespace be named "cython.view", > "cython.memview", "cython.memoryview", "cython.mview", "cython.memory", > "cython.buffer"? > > The functionality should be considered experimental until Cython 0.14, > but it shouldn't interfer as long as you don't use the above namespace > or the int[:]-syntax.
This will work well, I think -- with memoryviews implemented experimentally for an entire release, fwrap will be able to run the new functionality through its paces and address any bugs that come up. > > The gsoc-kurt branch has had the changes from cython-devel merged into > it and there's no real conflict, but some stuff left to do. The way > things are looking I suggest that: > > a) The closure branch gets to merge first > > b) We try to keep gsoc-kurt updated and merge it afterwards. Kurt should > hopefully be able to plan on gsoc-kurt being merged in time for 0.13 and > use it for fwrap development. > > Open tasks before we can merge gsoc-kurt: > - Types created by Cython output in wrong order (again!). This is > getting silly, and somebody, meaning me I guess, should code up a DAG > for outputting type declarations in their right order. See > http://trac.cython.org/cython_trac/ticket/469. > - memview_declarations fail due to "invalid use of follow specifier". > Kurt, could you have a look? I'll take a look, likely sometime this weekend. > > Open tasks we can look at after the merge: > - Consistent and better naming (memview vs. view vs. memoryview vs. > mview used in the source) Along with that: we discussed using the ampersand as the conjunctive for the different stride and memory access flags (I thought it was more pythonic, although less 'C'-like), or we could also go with the pipe (|) symbol instead, ala C flags. If it's already decided and behind us, then I'm fine with it. > - More memory efficient dynamic struct generation > - Item indexing > - Transform NumPy accesses to memoryview (probably not until 0.13.1 at > least). > > Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
