[Pyrex] [Cython-dev] cdef private class ... ?

Stefan Behnel stefan_ml at behnel.de
Sat Jan 12 10:22:09 CET 2008


Hi Kay,

Kay Hayen wrote:
> For the __all__ approach, what's wrong with using it? It works today in 
> CPython nicely and everybody already understands what it means (reading the 
> code). Only Cython would need an extension to understand it.
> 
> Plus, I thought about a decorator that would (for CPython) be implemented in a 
> way that it controls accesses to __all__ for that module at import time. That 
> may be very well feasible. Then it would work in both CPython and Cython with 
> the same and IMO elegant pure Python syntax.

I was long considering adding an __all__ to the lxml.etree module and never
got around to do it as it would require me to look through all defined classes
and names and maintain an up-to-date list of everything I want to export. I'm
stressing the word "maintain" here. It's really not something you do once, you
have to actively keep the list up-to-date.

Instead, I was always looking for an opt-out way to keep specific classes from
being exported. That's something you do once when you write the class and can
then forget about it. That's why I came up with the "private" proposal. It
immediately matches the primary use case.

Mind also that all that __all__ does in CPython is change the result of

    from module import *

which is rarely used anyway. Using __all__ does not keep you from importing
something explicitly, neither does it change what you see with "dir()".
Changing these semantics to a 'real' information hiding tool in Cython
wouldn't match CPython that well either.

Stefan




More information about the Pyrex mailing list