Re: A couple of questions about pyrex

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

Or "clevel" or "modlocal" or even "static", although Java/C++ users might
think of something else when they read "cdef static class"...

I'm ok with private also, then the meme would be that C things are module
local by default and Python things are publicly visible by default, unless
you explicitly decide otherwise.


> 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.

I guess the idea would just be to keep the name out of the module dict and
nothing else. That would make a "private class" a clear implementation detail.


> 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.

That would not keep it from bloating __dir__, though. In extension modules
that wrap many C things in module internal Python classes, this can really
make things less accessible.

OTOH, API doc generators can only work on things they see, and even
module-local /classes/ may have /instances/ that the user has to deal with...

Stefan