[C++-sig] Why Python for C++ programmers

Ralf W. Grosse-Kunstleve rwgk at yahoo.com
Wed Dec 11 01:27:49 CET 2002

--- David Abrahams <dave at boost-consulting.com> wrote:
> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
> > --- David Abrahams <dave at boost-consulting.com> wrote:
> >
> > I also find that debugging/testing my C++ algorithms is a lot faster if I
> > expose the new classes to Python from where they can easily be exercised
> with
> > different inputs. Almost all regression tests for my C++ algorithms are
> written
> > in Python.
> Surely the Python binding layer hides some of the variations on
> possible C++ inputs (e.g. const vs. non-const), making it impossible
> to fully-exercise some C++ interfaces?

I find it easier to debug my /algorithms/ from Python. This is very different
from exercising interfaces.

- Most of my algorithms require very complex inputs. It would take a lot of
time to write C++ code for generating these inputs.

- If things go wrong it is easy to insert print statements in Python to narrow
down the problem. This is much more time-consuming in C++ because of the
compilation/linking overhead.

- From Python I can easily try different inputs without inventing file formats
or recompiling. Being able to quickly change inputs or to systematically try a
range of inputs often is the key to finding out which of the many parts of a
complex algorithm is not functioning properly.

> Even discounting this issue, it's not obvious to me why it would be
> easier to write a Python binding layer just to test your C++ code.

Agreed. But of course I want the Python bindings anyway because this is the
most efficient way of putting together a large system. -- I realize my
arguments are a bit circular. Maybe it just comes down to: since I have a
hybrid system anyway I am free to choose how I implement the regression tests.
In practice I find it almost always more efficient to use Python for this


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.

More information about the Cplusplus-sig mailing list