Robert Bradshaw wrote:
> 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...
I forgot about module attribues. OK, let's just focus on object
attributes so that I can get my point through... I tend to look at
cdef class A:
cdef public int myfield
as a shorthand for (almost) this:
cdef class A:
cdef int _myfield
cdef property myfield:
def __get__(self): return self._myfield
def __set__(self, value): self._myfield = value
Rather than having to talk about both "exposed attributes" and
"properties" I'd rather just have properties. E.g.:
cdef class A:
cdef property int myfield
or similar.
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
