Hi Dag, Dag Sverre Seljebotn wrote: > those list-like types can likely share a lot of implementation with > my proposed int[:]; the major change would be restricting it to 1D, > different arithmetic behaviour, and, say, default coercion to list > instead of memoryview (perhaps!, but let's not go there now). But it > could still be PEP 3118-backed, coerceable from C pointers, etc., and > share implementation for that. Basically it would be two different > frontends to the same underlying type.
It would be great if those types could be implemented externally, i.e. without new syntax but with an import. Some special casing in the compiler may be ok (say, when Cython sees that the type defines some special method or attribute), but a complete implementation inside the compiler sounds wrong. > I suppose I'm still waiting for Stefan's opinion though, given his last > comment last week. Yes, I admit I'm a little slow in responding lately. ;) > I notice that I'm promoted to lead developer on the Cython front page > -- thanks! -- but I don't take it for granted that it should be a case > of majority vote, and at any rate I'd never push for something which > would make Stefan less interested in the project. That's not the case. You long deserve being 'promoted' (or rather 'named') lead developer and I appreciate the interest and support that we get from the numerics area. I think it's worth making Cython a suitable language for that area. > There are three levels: > 1) Memory-holding object. When Cython allocates, we need a new type > (probably inheriting directly from object), which allocates memory and > stores shape/stride information, and returns the right information in > tp_getbuffer. Would be a 20-liner in Cython unless we want to go with > PyVarObject for allocation in which case I suppose it is a 200-liner in C. I'm all for keeping such an implementation in Cython, at least for now. We can always optimise/reimplement later. > 2) The acquired Py_buffer on that object. Erm, buffers are not memory managed, right? They are just the plain structs that I think of? > That would happen the same way > as with every array; preferably by using memoryview, or if not, another > custom Python type (need to backport memoryview anyway) or if we can't > seem to avoid it a custom refcounted struct. If we implement the object ourselves, what do we need memoryview for? Would it not just implement the buffer protocol? Without any ref-counting? And when coercing to an object, why not just return the object itself? It could just have a C-level interface and a Python interface. 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. > 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... Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
