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

[Robert Bradshaw]

On Sat, Feb 26, 2011 at 6:14 PM, W. Trevor King <wking at drexel.edu> wrote:
> On Sat, Feb 26, 2011 at 10:01:43AM -0800, Robert Bradshaw wrote:
>> 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."
>
> What is the "Cython namespace"?  Is that what you get when you cimport
> something (vs. the Python namespace being what you get when you import
> something).

Yes, that would be a good way to understand it.

> If so, then that sounds like just two names, so
> name/cname it is.

Anything that exists in the intersection of the Cython and Python
namespace has the same name in both places--the user-visible one, thus
name suffices for both. (Also, the Cython namespace is a superset of
the Python namespace, possibly with a semantically equivalent but more
optimized backing for some objects, e.g. dispatching to C methods
directly for builtins.)

>> >> > 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?
>
> Yup, but I was trying to avoid pulling in non-Cython dependencies
> since you guys seem to have gone through a lot of trouble to make the
> Parsing module fast in C.

Ah, OK. It's not always obvious without looking what from the standard
library is fast and what is not, but this doesn't look particularly
optimized.

- Robert