[Cython] How to define C-consts in python module scope
vitja.makarov at gmail.com
Wed Jul 20 00:46:37 CEST 2011
2011/7/20 Lisandro Dalcin <dalcinl at gmail.com>:
> On 19 July 2011 02:24, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>> 2011/7/18 Robert Bradshaw <robertwb at math.washington.edu>:
>>> Trevor King and I discussed this quite a while back, but every time I
>>> got around to looking at his code (I don't think he ever created a
>>> formal pull request) something came up. The idea was that we could
>>> support cpdef structs and extern functions as well.
>> That's interesting, I think I shouldn't hurry with my pull request.
>> 2011/7/19 Robert Bradshaw <robertwb at math.washington.edu>:
>>> On Mon, Jul 18, 2011 at 4:34 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>>>> My suggestion is
>>>> cdef exposed enum:
>>> I agree, public is an overloaded word. This meaning is analogous to
>>> its use for cdef class members. Perhaps we should use "api" for api
>>> generation, and public used for Python-level access, with cpdef being
>>> the preferred form for declaring Python-accessible types.
>> It seems to me that cpdef is more cythonic but exposed could be used
>> in this case:
>> cdef extern from "ev.h":
>> exposed enum:
> And what about this?
> cdef extern from "ev.h":
> cpdef enum:
I'm fine with that, but cpdef seems to be a little bit confusing here.
On the other hand "cdef enum" is already supported inside "cdef extern" block.
I have implemented "cpdef enum" inside "cdef extern" block here:
I'm afraid that this change could introduce some side effects, however
it still passes all the tests
> BTW, how is this supposed to work with *.pxd files? I think the values
> will be exposed just in the matching implementation .pyx file, and not
> with cimport, right?
I thought about that too and I think it's correct behaviour. By the
way it's already working as expected.
More information about the cython-devel