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

[W. Trevor King]

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).  If so, then that sounds like just two names, so
name/cname it is.

> >> > 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.

> >> >> 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.

Ok, I'll merge those once I get the visibility kinks worked out of
Symtab.

-- 
This email may be signed or encrypted with GPG (http://www.gnupg.org).
The GPG signature (if present) will be attached as 'signature.asc'.
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20110226/76c7b6be/attachment.pgp>