[Pyrex] cdef private class ... ?

[Lenard Lindstrom]

I'm not sure this should be handled with new syntax. I suggest using the 
del statement to remove the extension name from the module's dictionary. 
Here is an example:

cdef class invisible:
    pass

del invisible

def new():
    return invisible()


Currently the del statement generates a couple of Pyrex compiler errors. 
Those errors could be removed so that 'del' can remove 'invisible' from 
the module's dictionary. This del statement may at first look confusing, 
implying that 'invisible' goes out of view for the rest of the module. 
But it makes sense with a proper specification of Pyrex's visibility 
rules. Every cdef, including 'cdef class', declares a C identifier local 
to the module. But 'cdef class' also adds an identical Python name. This 
Python name is hidden by the C identifier, with one exception. The C 
identifier does not hide a Python name in a del statement's list, since 
the del statement only involves Python names. So the Python name is 
deleted. The C identifier remains.


Lenard Lindstrom


Robert Bradshaw wrote:
> 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?
>>