[Cython] [cython-users] Cython .pxd introspection: listing defined constants
robertwb at math.washington.edu
Sat Feb 26 19:01:43 CET 2011
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
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.
BTW, I pushed https://github.com/cython/cython/commit/3552114e1b2a21bf2f81f451d50cd48934ea4eb4
which starts to do some of the back-end implementation.
More information about the cython-devel