[Python-Dev] Re: About Pyrex

[Ralf W. Grosse-Kunstleve]

> I had heard of it, but hadn't looked very closely at it.
> It looks interesting -- you seem to be approaching the
> problem from exactly the opposite direction, in a way.
> It's hard to get an idea of how your approach stacks
> up against mine, because they're so different.

It is not really "my" approach. David Abrahams deserves all the credit.
I came to Boost.Python as a user. My contributions are fairly minor in
the grand scheme of things.

> One thing I can say is that yours stands a better chance
> of coping with C++ in its full generality than mine
> does at the moment!

The most important feature for me is that both the compiled code and
the interpreted code look nice and are extensible.
The second most important feature is that all you need is Python
and C++. There is no third (little) language to learn (as with
SWIG).

> No, because in that example there's a lot of computation
> going on between each result. The inner loop there isn't
> the one collecting results, it's the one doing the divisions,
> which runs entirely in C.

In my world your example is not very typical. The algorithms that I
push to the compiled part of the system are usually operations that
work on arrays, and almost universally involve custom types (classes).

> In general -- if Python code needs to get at the results,
> they have to be converted to Python objects somewhere,
> somehow. I don't see a way around that.

Boost.Python gets around this by making it very easy to expose custom
types (C++ classes) to Python, incl. methods, dictionary, pickle
support etc. You may view Boost.Python as a high-performance extension
class factory. With the new Python 2.2 type system the Boost.Python
extension classes (in the ongoing rewrite) are indistinguishable from
regular built-in types. In future versions of Python this will also be
true for the native "new style" Python classes. I.e., there is no need
to convert C++ types from and to traditional Python built-in types.
Essentially, Boost.Python just attaches a reference count.
(David, please correct me if this view is not accurate.)

Ralf