On Sun, Feb 20, 2011 at 1:26 AM, Stefan Behnel <stefan...@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 _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
