On Sat, Feb 26, 2011 at 6:14 PM, W. Trevor King <wk...@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 <wk...@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 <wk...@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 _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
