On Oct 11, 2008, at 7:12 AM, Dag Sverre Seljebotn wrote: > Dag Sverre Seljebotn wrote: > >> What do I propose instead? >> a) That the reference-counted heap-allocated array stuff in the >> wiki >> is implemented first (with a list constructor). So the thing gets the >> semantics of a reference counted array, constructed again each >> time it >> is assigned (very similar to a Python list). >> >> b) That simple cases (where the pointer is never reassigned or >> copied, >> only written/read to/from by indexing) are then optimized to use >> stack >> allocation instead. >> > > First and foremost the point now is to . > > But, builing on this proposal, I propose that it is called > > cdef list[int] a = [1, 2, 3] > > and is not a subtype of list, but close enough: > > a) If it is not optimized (by b) above) it is a full Python object and > emulates most behaviour (but has much more efficient indexing). (If > only > efficient indexing is used then it is a C stack-allocated array.) > > b) "a = x", where x is a Python list, automatically converts > > c) "cdef list y = someobj" needs to have added auto-conversion from > list[type] > > This allows keeping the pointer types "clean" and without too much > magic, and also fits well with the buffer syntax etc. Users wouldn't > have to learn two different worlds for operating with C arrays and > NumPy > arrays.
I like this proposal, though I'd propose a new keyword (e.g. array) because list seems a bit odd (though it could be good, just not sure yet.) cdef array[int] a = [1, 2, 3] The question is not whether or not this is a better, more Pythonic way to do things, but whether or not anyone is going to hage time to implement this anytime soon (let alone by the next release). Yes, the arrays as they are now have a few warts (like using them in loops) but I think it's too useful to disable altogether. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
