[Cython] [cython-users] Cython .pxd introspection: listing defined constants
dalcinl at gmail.com
Mon Feb 21 19:38:06 CET 2011
On 21 February 2011 15:26, 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
>>> - usually "exported at the C level" in this kind of context, with the
>>> of meaning "modifiable at the Python level" for cdef class attributes.
>>> The potentially clearer "cpdef" means "overridable at the Python level"
>>> well as "visible at the Python level", so it doesn't quite match the
>>> 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
>>> 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
>>> 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
>>> I would also prefer if Python accessible cdef class attributes were
>>> using "cpdef". We could potentially make that the preferred way in the
>> 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
> 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...
But with a deprecation warning, right?
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext 1011)
More information about the cython-devel