On Sep 26, 2009, at 12:36 AM, Greg Ewing wrote: > Robert Bradshaw wrote: > >> It might be worth rethinking having two separate keywords to >> accomplish the same thing in different ways > > For Pyrex I've been thinking about dropping the 'api' keyword, > and having a compiler option that causes an api to be generated > for anything that's declared public.
Sounds like a good idea to me, though most people use distutils rather than invoking the compiler manually. (Most of the time you want a separate header, I assume your build process is more complicated anyways, but there might be distutils usecases). >> 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. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
