A) api also sets up the __pyx_api attribute, and is able to export static and mangled functions...would you link __pyx_api to public as well? Or just always imply api?
B) Is making public the default really backwards incompatible? Assuming pointers and structs are silently ignored or converted, it just makes a lot of stuff available which wasn't earlier, but it shouldn't break any code. With Python it is also the case that everything is public (well, except __name, which I'd be happy to use rather than introduce "private"). Dag Sverre Seljebotn -----Original Message----- From: Robert Bradshaw <[email protected]> Date: Sunday, Sep 27, 2009 3:33 am Subject: Re: [Cython] public keyword To: [email protected]: [email protected] On Sep 26, 2009, at 11:36 AM, Dag Sverre Seljebotn wrote: > >> Robert Bradshaw wrote: >> On Sep 26, 2009, at 6:09 AM, Dag Sverre Seljebotn wrote: >> >>> I'm all for replacing 'public'/'readonly', but I think it should >>> have >>> something to do with using the "property" keyword rather than >>> introducing another word. So +1 on the idea but -1 on "exposed". >> >> I'm not sure I follow you here... > >> I forgot about module attribues. OK, let's just focus on object > attributes so that I can get my point through... I tend to look at > >> cdef class A: > cdef public int myfield > >> as a shorthand for (almost) this: > >> cdef class A: > cdef int _myfield > cdef property myfield: > def __get__(self): return self._myfield > def __set__(self, value): self._myfield = value > >I think that's an implementation detail that doesn't need to be >exposed. Properties in Python are used to express lazy attributes, >and it's easier for the user to think of these as "normal" >attributes. (I also like the parallelism with structs.) > >> Rather than having to talk about both "exposed attributes" and > "properties" I'd rather just have properties. E.g.: > >> cdef class A: > cdef property int myfield > >> or similar. > >Right now we have > >cdef int x # struct member, totally private >cdef readonly int x # It's pretty clear what this means >cdef public int x # an overloaded keyword, which we'd like to get >rid of. > >If I were to go back and re-design it, I might name them private/ >readonly/[no decorator], but of course that's too backwards >incompatible. (Also, as a side note, "public" to me evokes accessible >from Python and "exported" evokes accessible from C (probably because >I think of things from the Python side more), but that would also be >a much more invasive change.) In any case, we're not going to break >old code, bit it'd be good to come up with a new keyword that means >accessible from Python (it'd be handy tag (external and locally >defined) enums and other cdef constants as having an Python- >accessible handle as well), and "property" doesn't evoke this for me >at all. > >I'm a huge +1 for getting rid of the api keyword and simply having a >directive/command line flag to emit a .h file for all public >declarations. (That way we could even specify the .h filename if >desired.) > >- Robert > >_______________________________________________ >Cython-dev mailing list >[email protected] >http://codespeak.net/mailman/listinfo/cython-dev > _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
