[Cython] [cython-users] Cython .pxd introspection: listing defined constants
robertwb at math.washington.edu
Mon Feb 21 19:11:59 CET 2011
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
We could allow it, but -1 to disallowing "cdef class"
More information about the cython-devel