[Cython] [cython] Hide Cython utility classes (like memoryview) from Python level module scope. (#222)

[Stefan Behnel]

Nikita Nemkin, 05.05.2013 14:26:
> On Sun, 05 May 2013 17:03:54 +0600, Stefan Behnel wrote:
> 
>> Nikita Nemkin, 04.05.2013 19:52:
>>> Two changes included:
>>>
>>> 1) cdef classes in utility code can have compiler directives attached to
>>> them. This is not used anywhere ATM, but memoryviews may benefit from
>>> ``@cython.final``.
>>>
>>> 2) All utility classes are excluded from module dictionary by
>>> *implicitly* marking them with ``@cython.internal`` . This fixes
>>> [#775](http://trac.cython.org/cython_trac/ticket/775), test is included.
>>>
>>> I don't quite understand what CythonScope is and how utility classes
>>> are *supposed* to be hidden, but as it is now, utility code scope is
>>> merged into main module scope and there is nothing special about its
>>> classes.
>>>
>>> BTW if a user declares his own class with the same name as utility class
>>> (for example, ``memoryview``), everything breaks down.
>>
>> I wonder why utility classes actually need a Python name. Can't they just
>> live with None as "name"? All they should really need is their cname and a
>> properly analysed entry stored in the right places, so deleting their
>> Python visible name when merging them into the main module should fix this.
> 
> entry.name serves for general identification and bookkeeping, not just
> to provide a python level name. Non-null entry name is a very useful
> invariant, I'd rather not break it for something trivial like name hiding.
> 
> All codegen algorithms will have to worry about (class) entries with null
> names afterwards. Even if it works currently, it may break in the future.
> 
> Anyway, just setting entry.name to None does not work, because it is not
> the only place to get a python name (and of course it's never checked for
> None).
> For example, module init code uses ClassScope.class_name. Some other code
> may use entry.type.name etc...

Ah, yes. It's way more complex for classes than for, say, lambda functions
(and even those have a fake name).

Anyway, given how easy it is to declare utility code @internal to get this
fixed, I think it's not worth looking for a different solution.

I merged your pull request.

Stefan