On Sat, Sep 26, 2009 at 10:09 AM, Dag Sverre Seljebotn <[email protected]> wrote: > > Lisandro already went part of the way with the callspec("string") > feature, which I think could take care of the DL_EXPORT etc.. The other > components to "public" are name mangling and loosing the static > modifier, both of which could be usable as seperate instructions (for > cases where you either want to link in other object files or link in > inline C code from header files). > > > @cython.c_mangle(False) > @cython.c_static(False) > @cython.callspec("DL_EXPORT") > cdef myfunc(): ... >
Well, yes and no... using 'callspec' for "DL_EXPORT" is kind of an abuse... Perhaps better it would be @cython.storagespec(extern=True, C=False) cdef myfunc() were by default 'extern' would be 'False' (meaning a 'static' is used in the generated C code) and 'C' being 'True' by default (to avoid potential problems with C++, as Cython does not currently support overloaded function, no point in defaulting to C++ func overloading) > Given all of this, I'd be happy to drop "public" (not remove from > language, but remove from docs). > >>>> On Sep 25, 2009, at 9:35 AM, Lisandro Dalcin wrote: >>>> >>>>> The first way, related to the "public" keyword, is based on >>>>> DL_EXPORT/DL_IMPORT stuff and CROSS-LINKING extension modules. >>> It's actually designed for making things available to >>> C code that's statically linked with the extension module. >>> Dynamic linking between extension modules is not something >>> I ever intended to support. >> >> Are the mechanisms documented anywhere? (I could look at the code I >> guess, but I'm not a linking expert, nor have I ever needed this to >> see how it really works...) >> >>>> Currently, public is a bit odd, as it's also used in an >>>> unrelated context to expose cdef attributes. >>> Yes, that's not really the best. I've been thinking about >>> replacing this usage with something else, such as 'exposed'. >>> That could be used for other purposes as well, such as >>> exposing enum values to Python code. >>> >>> Then there would be a consistent rule -- 'public' is for >>> making things available to C, 'exposed' is for making >>> them available to Python. >> >> >> +1, though for backwards compatibility we'll still want to support >> public in those contexts. > > I'm all for replacing 'public'/'readonly', but I think it should have > something to do with using the "property" keyword rather than > introducing another word. So +1 on the idea but -1 on "exposed". > > > > -- > Dag Sverre > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev > -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
