On Feb 24, 2010, at 6:41 AM, Lisandro Dalcin wrote: > On 24 February 2010 03:24, Robert Bradshaw <[email protected] > > wrote: >> On Feb 23, 2010, at 7:13 AM, Lisandro Dalcin wrote: >> >>> Bump! >>> >>> On 18 February 2010 04:27, Stefan Behnel <[email protected]> >>> wrote: >>>> Lisandro Dalcin, 17.02.2010 23:38: >>>>> What is not clear to me is the following: Should "public", >>>>> "api", or >>>>> "public api" have any semantic diference? >>>>> [...] >>>>> Greg said that he never intended to provide DLL export >>>>> mechanisms, and in fact he just wanted to make stuff available >>>>> across >>>>> compilation units (i.e, make stuff available to other C source >>>>> files >>>>> being compiled ALONGSIDE the generated C sources to build the >>>>> final >>>>> ext module). If we enforce this, I mean we are not going to >>>>> support >>>>> ext module interlinking, then almost the usages of DL_IMPORT/ >>>>> DL_EXPORT >>>>> macros are a nonsense and should be removed, alongside almost all >>>>> these dll_linkage arguments in many methods. >>>>> [...] >>>>> So... What do you think? >>>> >>>> My take is that public symbols are only portably usable at static >>>> link >>>> time, so supporting more is simply not worth it. Even static >>>> linking >>>> against symbols exported by a Cython module should be a very rare >>>> use case. >>>> It's not used when calling external C code nor is it worth anything >>>> when >>>> providing callbacks into the Cython code. Most of the time, the >>>> external >>>> code will be there first and will be used by the Cython code, not >>>> the other >>>> way round. This mechanism shouldn't be seen as something that's >>>> usable at >>>> dynamic linking time. There's public C-API support for that. I >>>> second your >>>> intuition that the DL_EXPORT stuff can be dropped completely. >>>> >>> >>> OK. >>> >>>> There's also the use case of statically linking multiple Cython >>>> modules >>>> into one extension module. This isn't currently supported (really), >>>> and >>>> there's more to do to make it run smooth. >>> >>> Are you talking about the limitations/gotchas in Python's import.c >>> implementation ? >>> >>>> But I don't think it would >>>> interfere with the above in any way. >>>> >>> >>> Of course. >>> >>> Anyone has something to add? Greg? >>> >>> Still... What should we do with 'public' and 'api' keywords? >> >> I don't really use either, so while I agree that it would be nice to >> clean things up, I don't want to break backwards compatibility. >> (Judging from the lack of activity on this thread though, it seems >> they're not in high demand, though sage-support should be pinged if >> we >> plan on getting rid of anything.) 'public' should probably still mean >> what it always has. >> > > Could you explain me the exact meaning of 'public' (alone, without > 'api')?
Doesn't it simply avoid mangling names? (It may have other side effects as well.) - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
