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." 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 _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
