On 20 July 2011 18:06, Lisandro Dalcin <dalc...@gmail.com> wrote: > On 19 July 2011 20:48, Robert Bradshaw <rober...@math.washington.edu> wrote: >> On Tue, Jul 19, 2011 at 3:02 PM, Lisandro Dalcin <dalc...@gmail.com> wrote: >>> On 19 July 2011 02:24, Vitja Makarov <vitja.maka...@gmail.com> wrote: >>>> 2011/7/18 Robert Bradshaw <rober...@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 <rober...@math.washington.edu>: >>>>> On Mon, Jul 18, 2011 at 4:34 PM, Greg Ewing <greg.ew...@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: >>>> EV_READ >>>> EV_WRITE >>>> >>> >>> And what about this? >>> >>> cdef extern from "ev.h": >>> cpdef enum: >>> EV_READ >>> EV_WRITE >> >> Yep, exactly. >> >>> 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? >> >> It would be an error unless there's an corresponding .pyx file (which >> could be empty). The idea is that one could also define extern cpdef >> functions and structs and wrappers would be provided. >> > > It would be an error? What do you mean? if you cpdef enum in foo.pxd, > and have foo.pyx, then the enumerations should be exposed in the 'foo' > module. But then if you "cimport foo" in bar.pyx, that should succeed > but the enumerations should not be exposed in the "bar" module... Am I > missing something? >
I believe Robert confirmed what you said and added to that that it would be an error to have a cpdef extern enum in a .pxd without a corresponding .pyx file. > -- > Lisandro Dalcin > --------------- > CIMEC (INTEC/CONICET-UNL) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1011) > Tel/Fax: +54-342-4511169 > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
