[Numpy-discussion] restricting object arrays to a single Python type
scopatz at gmail.com
Wed Jul 17 01:50:17 EDT 2013
On Tue, Jul 16, 2013 at 7:15 PM, Geoffrey Irving <irving at naml.us> wrote:
> On Tue, Jul 16, 2013 at 4:51 PM, Anthony Scopatz <scopatz at gmail.com>
> > Hi Geoffrey,
> > Not to toot my own horn here too much, but you really should have a look
> > xdress (http://xdress.org/ and https://github.com/xdress/xdress).
> > will generate a wrapper of the Force class for you and then also create a
> > custom numpy dtype for this class. In this way, you could get exactly
> > you want.
> Unfortunately it's unlikely to work out of the box, since it uses
> gccxml which appears to still be based on gcc 4.2. All of our code is
> C++11, and we need to preserve portability to horrible places like
> Visual Studio (yes, these two constraints are just barely compatible
> at the moment).
I don't think that GCC-XML should be a show stopper. There are a couple of
reasons for this. The first is that, correct me if I am wrong, but most of
the C++11 updates are not really changes that affect top-level API elements
-- which is the only thing that you care about when creating wrappers. So
unless you are relying on a lot of lambdas or something, my guess is that
GCC-XML might just work anyways.
The second reason is that xdress is written to be *very* modular. There is
no reason that it needs to rely on GCC-XML at all. Other parsers and ASTs,
such as Clang or SWIG or ROSE, could be used. In fact there is a mostly
complete version of a Clang AST present in XDress already. I have disabled
it and am not worrying about it personally because the current Clang Python
AST bindings do not support template arguments. Since this is a major use
case of mine, I had to abandon that code line. However, other people could
forge ahead with Clang in one of a few ways:
1. Use the nascent XML output of Clang,
2. Use the existing Clang Python AST bindings, understanding that they
3. Fix the Python Clang AST bindings
4. Write your on Python Clang AST Bindings (I know people who have done
this but they are not open sorce), possibly using XDress!
In any event, none of this is super difficult, wouldn't impair xdress
development at all, and everyone would benefit. Alternative parsers are
something that is on my radar and I would love to support.
> > If you run into any trouble, let me know and I'll be sure to help you
> > This is the kind of thing that xdress is supposed to do so bugs here are
> > big priority for me personally =)
> We're currently using a custom Python binding layer which I wrote a
> while ago after getting fed up with boost::python.
I have been down that painful road =)
> Our system is
> extremely lightweight but also limited, and in particular is missing a
> few key features like automatic support for named and default
> arguments (since these can't be introspected inside C++).
XDress supports these.
> It'd be
> great to chat more about our two feature sets and whether there are
> opportunities for collaboration and/or merging. I'm not sure if this
> list is a good place for that discussion, so we could optionally take
> it off list or to skype if you're up for that (send me an email
> directly if so).
I'd be happy to! My skype name is 'scopatz' or you can find me on Google+.
I tend not to just hang out on skype and I have a lot to do tomorrow, so if
you want to set a time that would probably be best. My schedule is pretty
flexible if busy.
> Here are links to our system, which unfortunately is undocumented at the
> # Unit test for wrapping a class
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion