[Cython] Type scope vs. runtime scope

[Dag Sverre Seljebotn]

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?
>
> 2) How would this act differently from what I proposed? (Well, it only
> acts on typedefs...)
>
> 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.)

OK what about this:

1) The above is illegal, because it is all under Cython control.

2) If you have a cimport with the same name as an import, then ctypedefs
of non-cdef-classes in the cimport do not affect the runtime namespace of
the import.

It has complexity against it though; simply allowing the example above
might be more straightforward and much less magic. Users don't have to
shoot themselves in the foot even if we let them.

Dag Sverre