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

[W. Trevor King]

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.

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

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

-- 
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/df2debdb/attachment.pgp>