On Aug 5, 2008, at 12:06 AM, Dag Sverre Seljebotn wrote: > Robert Bradshaw wrote: >> >> On Aug 4, 2008, at 11:36 PM, Dag Sverre Seljebotn wrote: >> >>> 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... >> >> OK, I completely missed the point of what you were trying to do last >> time (I blame bad linewrapping in the numpy.zeros function ;-). >> >> What if, when you wrote >> >> ctypedef npy_int64 int64 >> >> it would do a check to see if int64 was already defined (as a normal >> variable) and if so would attach that information to the type (same >> as with extension types that have a dual nature). When used in a >> variable context it would extract this information > > 1) But you do not know if int64 is already defined until run-time?
Unless one is using the import *, one always knows. > 2) How would this act differently from what I proposed? (Well, it only > acts on typedefs...) typedefs are the only way to make new c types anyways. I guess it is essentially the same, I was just thinking of it from a different angle. > > What I am asking here is not how to implement it (I'll have a look > at the > source before asking that), but how the language should behave. Is > this > wanted behaviour, or is > > ctypedef int x > x = 3 > cdef x v = x > > too scary? (Which seems to be a consequence of your proposal as > well, if > it is not the same as mine.) Yes, I guess that is the behavior we want. We already handle int vs. int, list vs. list, CdefClass vs. CdefClass, so I guess we could do this. On that note, why doesn't it die when you put "int" in there instead? Hmm... - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
