[Pyrex] cdef private class ... ?

[Robert Bradshaw]

Sounds like a good proposal to me.

On Jan 10, 2008, at 9:45 AM, Stefan Behnel wrote:

> Hi,
>
> I was thinking about module namespace pollution a bit more. What  
> about adding
> a class modifier "private" that keeps a class from appearing in the  
> module
> dictionary?
>
> The reasoning is that it is not so uncommon to define a non-public  
> class, e.g.
> for passing internal (C) values through Python space or for keeping
> "self-deallocating" context pointers around. Currently, there isn't  
> a way to
> say: "the module uses that class internally, but the user shouldn't  
> care", and
> especially "the user *must not* instantiate that class" for  
> whatever reason
> (uninitialised pointer fields, for example). The easiest way to  
> deal with that
> would be to just keep the class name out of the module dictionary.
>
> I know that this is not a 'secure' solution as users can still  
> instantiate it
> when they get an instance in their hands, but I don't consider that  
> worth
> bothering. I'm more concerned about having it pop up when you say
> "dir(module)". If users don't get in touch with it unless they  
> explicitly
> introspect it, that's by far enough.
>
> Also, since we were discussing some optimisation ideas on the  
> Cython list
> lately, this would allow the compiler to see (or enforce?) that the  
> class
> 'can' not be subclassed from Python space so that it can optimise  
> away some
> overhead like garbage collection support if the class doesn't  
> contain Python
> object fields, or the Python instantiation overhead if the class  
> doesn't use
> __init__() - instantiation could automatically use the tp_new()  
> fast path in
> that case.
>
> I considered "static", which is the C equivalent, but since that  
> has a totally
> different meaning in another C-like big-buzzword coffee-language, I  
> prefer
> "private" here, which I find much more explicit.
>
> Any comments?
>
> Stefan
>
>
> _______________________________________________
> Pyrex mailing list
> Pyrex at lists.copyleft.no
> http://lists.copyleft.no/mailman/listinfo/pyrex