Re: [Cython] Python type optimizations (NumPy GSoC-related)

[Dag Sverre Seljebotn]

Greg Ewing wrote: Dag Sverre Seljebotn wrote: And this difference in behaviour comes entirely from strides having a name-clash while shape/dimensions do not. I missed the beginning of this, so I'm not sure exactly what problem is being discussed here, but I suspect you're making all this much more complicated than it needs to be. The beginning of it is a project that aims for making Cython more attractive for numerical computation. This is far from the goals of the Pyrex ancestor, however it is still very attractive because it /already/ works great technically, it is just that it needs a lot of syntax and manual fiddling with the underlying NumPy extension type and so the Cython code that is needed is quite horrible. More info: http://wiki.cython.org/DagSverreSeljebotn/soc Especially, consider the very last section ("Current access method") of this page: http://wiki.cython.org/enhancements/numpy If a name clash is the only problem, it should be easily resolvable by using a C name declaration to give the offending attribute a different name in the Pyrex/Cython code. The problem here is that Python users who just want to "type their code and get speedups" will then have to learn to use different names for accessing the object at the different layers. Ideally, they shouldn't have to care about the extension type at all. So, no, the name clash is not the only problem, the plan is to add a lot of syntax candy, and the declaration of that syntax candy must be put somewhere. Until now it was assumed it would just go into the declaration of the extension type, but now I think this would be messy and unnatural. -- Dag Sverre

_______________________________________________
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev