[Pyrex] A couple of questions about pyrex
Stefan Behnel
stefan_ml at behnel.de
Wed May 13 07:09:17 CEST 2009
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
More information about the Pyrex
mailing list