[Cython] [cython-users] Cython .pxd introspection: listing defined constants

[Robert Bradshaw]

On Sat, Feb 26, 2011 at 3:48 AM, W. Trevor King <wking at drexel.edu> wrote:
> On Fri, Feb 25, 2011 at 11:11:03PM -0800, Robert Bradshaw wrote:
>> On Tue, Feb 22, 2011 at 12:02 PM, W. Trevor King <wking at drexel.edu> wrote:
>> > An easy, if uglier, workaround would be to prepend attributes with the
>> > class name, e.g. CBinding.visibility -> CBinding.c_binding_visiblity.
>> > Then the Ctx class could subclass the current CtxAttribute classes
>> > instead of binding instances of each of them.  That way Ctx would keep
>> > its traditional flat attribute namespace and easy deepcopy, but
>> > eveyone in Nodes, etc. that will use the attributes would become
>> > class-name dependent.
>>
>> I'd be up for flattening this. In particular, changing every
>> "entry.name" to "entry.python_binding.name" seems to be a lot of churn
>> and extra verbiage for not much benefit. The only overlap I see is
>> name and visibility, and keeping name/cname and adding cvisibility
>> would be preferable to me.
>
> That works for me, but I see possible ambiguity in cname.  From the
> "external C code" docs:
>
>    The other way is to use a C name specification to give different
>    Cython and C names to the C function. Suppose, for example, that
>    you want to wrap an external function called eject_tomato(). If
>    you declare it as:
>
>    cdef extern void c_eject_tomato "eject_tomato" (float speed)
>
>    then its name inside the Cython module will be c_eject_tomato,
>    whereas its name in C will be eject_tomato.
>
> In this case I was eventually going to use
>
>    c_source.name = eject_tomato
>    c_source.namespace = ...
>                c_binding.name = c_eject_tomato
>    c_binding.namespace = ...
>                python_binding.name = eject_tomato
>
> I'm not sure how Cython handles name/cname with this case at the
> moment, but it seems like there are two cnames to keep track of.

In this case, cname is "eject_tomato" (which actually gets emitted in
the C source file to use it) and name (in both Python and Cython
namespace) is "c_eject_tomato." You can think of it as name being what
the user sees, and cname being what the C compiler sees.

>> > The CtxAttribute class is, as its docstring says, just a hook for its
>> > deepcopy method.  With an alternative deepcopy implementation,
>> > CtxAttribute could be replaced with the standard `object`, so don't
>> > worry too much about its name at this point ;).
>>
>> You mean shallow copy?
>
> I meant deepcopy, since that seems to be the point of Ctx cloning.  At
> the moment, however, Ctx deep copies only require Binding shallow
> copies.  If someone crazy wanted to add mutable attrubites to binding
> classes, the Binding deepcopy code would have had to be adjusted.
> None of this matters though, if we move back to a flat Ctx attribute
> space.

OK. As an aside, do you know about the copy.deepcopy() method?

>> >> CSource: doesn't sound like quite the right name - it does not describe a C
>> >> source file but information that Cython has about non-Cython things.
>> >
>> > It's a container for attributes that describe the presence and
>> > location of backing C definitions.
>> >
>> > * cdef: "Will there be a backing C defintion?
>> > * extern: "Has someone else already written it?"
>> > * name/namespace: "What did they call it?"
>> >
>> > If you'd rather I called the class something else, I'm certainly
>> > willing to change it.
>>
>> It seems a bit odd to me, but if need be we can rename it later.
>> However, csource and c_binding seem rather redundant to me, but as
>> mentioned above I think it's better just to flatten it all.
>>
>> The changes to parsing look decent to me, but admittedly there's a lot
>> of renaming churn, so I could have missed something.
>
> I'll go back and revert out the name changes if you'll confirm that
> there is only one meaning for cname.

Thanks.

BTW, I pushed https://github.com/cython/cython/commit/3552114e1b2a21bf2f81f451d50cd48934ea4eb4
which starts to do some of the back-end implementation.

- Robert