[Cython] [cython-users] Cython .pxd introspection: listing defined constants
robertwb at math.washington.edu
Sun Feb 27 04:11:48 CET 2011
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
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
More information about the cython-devel