[Cython] [cython-users] Cython .pxd introspection: listing defined constants

[Robert Bradshaw]

On Sun, Feb 20, 2011 at 1:26 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> W. Trevor King, 20.02.2011 00:31:
>>
>> On Sat, Feb 19, 2011 at 02:04:16PM -0800, Robert Bradshaw wrote:
>>>
>>> On Sat, Feb 19, 2011 at 1:45 PM, W. Trevor King wrote:
>>>>
>>>> It is unclear to me what `cdef public struct` means.  I think it
>>>> should mean "Python bindings can alter this struct's definition",
>>>> which doesn't make sense.
>>>
>>> I think it should mean "this struct is accessible from Python (as X)"
>>
>> Wouldn't that be "cdef readonly struct X"?
>
> The problem here is that "public" is used differently in different contexts
> - usually "exported at the C level" in this kind of context, with the quirk
> of meaning "modifiable at the Python level" for cdef class attributes.
>
> The potentially clearer "cpdef" means "overridable at the Python level" as
> well as "visible at the Python level", so it doesn't quite match the second
> meaning by itself.
>
> Structs won't be overridable at the Python level, I guess, so cpdef isn't
> quite right. The intention here isn't to export them at the C level either,
> so "public" isn't right.
>
> We could tweak the "cpdef" meaning into "cdef thing mapped to the Python
> level, and overridable if supported in the given context", which would lead
> to broader applicability. Then we could allow

That's what I was thinking.

>    cpdef readonly struct ...
>
> I think that's a lot clearer than adding to the double meaning of "public".
> I would also prefer if Python accessible cdef class attributes were defined
> using "cpdef". We could potentially make that the preferred way in the
> future?

We could allow it, but -1 to disallowing "cdef class"

- Robert