[Pyrex] A couple of questions about pyrex

[Yingjie Lan]

--- On Tue, 5/12/09, Franck Pommereau <pommereau at univ-paris12.fr> wrote:

> From: Franck Pommereau <pommereau at univ-paris12.fr>
> Subject: Re: [Pyrex] A couple of questions about pyrex
> To: lanyjie at yahoo.com
> Cc: "Stefan Behnel" <stefan_ml at behnel.de>, pyrex at lists.copyleft.no
> 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