Hi Dag, thanks for writing this up (and for insisting :).
Dag Sverre Seljebotn wrote: > Thanks to everybody who contributed to the discussion on a Cython array > type last week! Here's a summary to attempt focusing the discussion. > > There are now two CEPs: > - CEP 517, array type: http://wiki.cython.org/enhancements/array > - CEP 518, SIMD operations: http://wiki.cython.org/enhancements/simd > [...] > c) It would be nice to finally settle a roadmap for numerics in Cython > (how far will the language be bent for the benefit of numerics), for > instance to economize on discussions when questions pop up on the > mailing list (and make plans). These two CEPs would create one such roadmap. > [...] > a) Numerical users seem positive about all of this. > b) Robert Bradshaw said: > > I am not opposed to this feature, despite it being off the path of > being a good, optimizing Python compiler with easy glue to external > code, as long as it doesn't intrude on the language too much. Mostly, > this is because there is so much interest in using Cython in a > numerical processing context. I do, however, have some reservations. > > [I believe the reservations were all taken care of.] > > c) I'm not sure about Stefan Behnel's current opinions about this. I'm not involved in numerics, so I can't comment on the feature impact. >From my POV, every addition that doesn't 'degrade' (i.e. complicate) either the language or the compiler code is just fine. Every addition that requires major syntax support will almost always invoke a discussion, as seen here. IMHO, getting a feature without syntax impact is a lot better than yet another way of overloading and extending some bracket syntax. Regarding CEP 517, I think that a 'native', memory managed array type would be very helpful in a fair lot of use cases. Plus, (most of) this can be done in an external module. So that's a perfect new feature. Solving ticket 152 (PyVarObject support) first would be helpful to this end. Regarding CEP 518, I do see the interest, and I do see why this cannot be done externally. But I also see that there were doubts that this is enough to be truly useful except for a number of cases. And it has some impact on the language. We had a discussion about parallelism in the language a while ago, which lead to this write-up: http://wiki.cython.org/enhancements/parallel Nothing happened since then, as ticket 211 shows. I like the idea of parallelism in the language in general, and I'm not opposed to CEP 518. I'd just like to see it added in a way that clearly separates it from the 'normal' array type. What would be better for the intended use case: allow parallelism in the language in general (i.e. parallel loops), or have a parallel type that does some magic behind the scenes? Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
