On Mon, Feb 21, 2011 at 10:26 AM, Stefan Behnel <stefan...@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 http://trac.cython.org/cython_trac/ticket/654 - Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
