Re: A couple of questions about pyrex
Yingjie Lan <[email protected]> Tue, 12 May 2009 15:54:21 -0700 (PDT)
| Newsgroups | gmane.comp.python.pyrex |
|---|---|
| Message-ID | <[email protected]> |
--- On Tue, 5/12/09, Robert Bradshaw <[email protected]> wrote: > From: Robert Bradshaw <[email protected]> > Subject: Re: [Pyrex] A couple of questions about pyrex > To: "Franck Pommereau" <[email protected]> > Cc: [email protected], [email protected] > Date: Tuesday, May 12, 2009, 10:54 PM > On May 12, 2009, at 9:15 AM, Franck Pommereau wrote: > > >> Think further down the road after that is done, > >> if some day we decided to use 'cdef class' > for > >> private class definitions > > > > I don't think that cdef should be interpreted as > private. But it means > > that what follows is a native object (ie, implemented > in C) instead of a > > Python object. > > +1 > > > So if you cdef a type, a variable or a function, there > is no way to > > access it from Python because C and Python have > different conventions > > for such objects (eg, Python uses name bindings in > environment and has > > no proper notion of variable, and calling conventions > are different also). > > > > On the other hand, if you cdef a class, there is no > way to see it as a > > class from C because there is no such notion here. But > anyway you get a > > class implemented in C, which is considered a builtin > class by Python. > > > > Presented this way, it looks fully consistent (at > least to me). > > > cdef statements are used in a variety of declaration > scenarios (cdef classes, cdef extern blocks, cdef variables > and methods) and I think the best way to think about them is > "something at the C level is going on here." In > any case, the current syntax is not going away/changing > meaning if just for backwards incompatibility reasons. Also, > the distinction between classes and types is still large > enough that on needs to distinguish them, and "explicit > is better than implicit." > Just like python 3.0, backward compatibility can be handled in a graceful way -- only a simple replacement, easier than what has been done with python 3.0, and this can be done not only with codes to be compiled by pyrex, but also with the pyrex/Cython documentation). I would say it is quite painless. The main challenge, of course, is with the implementation. More thought work need to be done before any action taken. yingjie