Re: A couple of questions about pyrex

Yingjie Lan wrote:

> So this is why I don't think it is intuitive:

Nothing is ever going to be completely intuitive to
everyone. The best you can hope for in language
design is to have some kind of logic behind the
decisions made.

> If 'def' defines a function usable by python,
> then I would naturally expect 'class' define
> a class usable by python too, right?

And it does.

> If 'cdef' define a function hidden from python,
> why 'cdef class' define a class for python?

The reason you use 'cdef' to define a function
isn't to hide it from Python -- it's to create a
function that can be called directly from C code.
The fact that you can't call it from Python is
just a consequence of that.

'cdef' doesn't mean 'private', it means 'this has
something to do with C'. What exactly it has to
do with C depends on the kind of thing it's
applied to.

Possibly 'cdef' wasn't the best choice of word
for defining an extension type, but I didn't want
to introduce any more new keywords than necessary,
and there wasn't anything else that I wanted to use
'cdef class' for.

> I would expect 'cdef class' define an invisible
> class (for internal use of the module) in a
> pythonic way (making things easier).

Hiding things from Python would be better done
using some explicit keyword such as 'private',
which could be applied to other things besides
classes.

However, note that there is no way of completely
preventing Python code from getting access to a
class, because there are various indirect ways of
getting to classes even if they're not directly
exported. So there wouldn't be much point in
having private class declarations.

You can always give the module an __all__ attribute
that omits the class if you don't want to advertise
it as part of the API.

-- 
Greg