Re: A couple of questions about pyrex
Yingjie Lan <[email protected]> Tue, 12 May 2009 15:33:34 -0700 (PDT)
| Newsgroups | gmane.comp.python.pyrex |
|---|---|
| Message-ID | <[email protected]> |
--- On Tue, 5/12/09, Franck Pommereau <[email protected]> wrote: > From: Franck Pommereau <[email protected]> > Subject: Re: [Pyrex] A couple of questions about pyrex > To: [email protected] > Cc: "Stefan Behnel" <[email protected]>, [email protected] > Date: Tuesday, May 12, 2009, 8:15 PM > > 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. Sure, I am talking in the sense that native = private (invisible to python) pythonic = public (visible to python) > > 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. Right now, as Stefan already said it, we don't support native/private class yet. But, if in the future we choose to do so, 'cdef class' would be the ideal syntax. Just like you write a java or C/C++ module, you can have classes/structs/unions etc kept within the module. Of course, right now you can have 'cdef struct' that will work that way, but those things are not syntactically as easy to use as a pythonic style class. So, if pyrex can provide such a private, pythonic class, that would be wonderful. The use of those private classes (such as method access, etc) can be translated into pure C/C++ code, so the overhead would be minimal, but the easy of use would be something valuable to consider. yingjie > > Presented this way, it looks fully consistent (at least to > me). > > Cheers, > Franck