Robert Bradshaw wrote:
> 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).
I think that rather than merging things together, one should split
what's combined into "public" up.
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(): ...
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
