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

Robert Bradshaw robertwb at math.washington.edu
Mon Feb 21 19:38:47 CET 2011

On Mon, Feb 21, 2011 at 10:26 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Robert Bradshaw, 21.02.2011 19:11:
>> On Sun, Feb 20, 2011 at 1:26 AM, Stefan Behnel 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"
> With "preferred way", I was suggesting that we could *deprecate*
>    cdef public int x
>    cdef readonly object y
> for cdef class properties in favour of
>    cpdef int x
>    cpdef readonly object y

Oh, you were talking about members. For sure.

> and change the documentation accordingly etc., so that at least new users
> get used to the new way. The old way would likely continue to be supported
> until Cython 2.0 or so, for the holy cow's sake...


This kind of thing is much easier to fix than, say, fallout from

- Robert

More information about the cython-devel mailing list