On Sep 26, 2009, at 6:09 AM, Dag Sverre Seljebotn wrote:
> 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).
This gets really verbose if you have a lot of public methods/
classes/..., so I'd say especially since we already have the public
keyword we might as well keep it. Also, there might in the future be
other modifiers we might want to add to public for ease of use.
>>>> 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".
I'm not sure I follow you here...
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
