Robert Bradshaw wrote: > On Aug 3, 2008, at 12:44 PM, Dag Sverre Seljebotn wrote: > >> In numpy.pxd I want to have this: >> >> ctypedef npy_int64 int64 >> >> and be able to use it like this (this is what a NumPy user would >> expect >> to do): >> >> cimport numpy >> cdef numpy.ndarray[numpy.int64, 2] = numpy.zeros([10, 10], >> numpy.int64) > > Yes. > >> This however creates an error: >> 'int64' is not a constant, variable or function identifier >> >> since int64 is declared as a type in the scope. > > Where is this error being thrown from? Perhaps it could/should be > checked after the buffer transforms?
The problem is that once numpy.int64 is declared as a ctypedef, it is not longer available to be called at runtime as a python object, so you cannot get the reference to pass to numpy.zeros. To be clear, in numpy.pxd it says cdef extern ... : ctypedef int npy_int64 ctypedef npy_int64 int64 while some consequence of numpy/__init__.py deep down somewhere is assigning something to the int64 attribute of the numpy module. (This has nothing to do with buffers.) One solution is requiring people to do "cimport c_numpy", but I'd like to avoid that as well. Unless this is resolved (on a language design level, technically it as too many solutions...), I need to figure out a way to mangle the names without loosing usability too much... >> Warning! In theory, this principle could allow code like >> >> x = 4 >> ctypedef int x >> cdef x v = x > > I'm not completely following that, but it looks scary. My proposed solution is to allow that ctypedefs and other type declarations in general do not alter the "runtime scope", so that the "type named x" and "module attribute named x" are two different things and can be referenced by the same name from the same scope. >> If you didn't like this but have time, you could have a look at >> >> http://wiki.cython.org/enhancements/runtimectypes >> >> which is another proposal I could use to achieve my ends, however I'm >> reluctant to think or discuss something going so much into language >> design right now. > > > I'm not sure I like that proposal either. I'm not too happy about the syntax I proposed, where to put the declarations etc. But I still like the general concept of having something say "use this C type, but when coercing to a Python object use this class". This would be a perfect fit for the numpy types as you can currently do P> a = numpy.float64(34) P> 34.0 P> type(a) <instance "numpy.float64"> (or something like that), so having cdef numpy.int64 x and have x coerce not to a Python int but a (runtime) numpy.int64 would be nice, even though the compile-time int64 is an entirely different beast it expresses the same information and exposes about the same API (same operators behave in the same way). Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
