On Sep 27, 2009, at 1:34 AM, Dag Sverre Seljebotn wrote: > 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?
This is another example of redundancy of api. If you declare a function in a .pxd it sets up the __pyx_api attribute. If you don't, you can't really use it from another module anyways. > 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"). I consider it backwards incompatible because currently classes can safely assume invariants about their non-public attributes, which would no longer be the case. No, it wouldn't break existing code, but it would change the guarantees the current semantics imply. > > 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 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
