RE: [boost] py_cpp

From: Moore, Paul (paul.moore_at_[hidden])
Date: 2000-10-19 04:49:43

From: David Abrahams [mailto:abrahams_at_[hidden]]
> > FWIW, my view is that the "official" Boost
> > libraries should be an extension of the C++
> > standard library, in principle. That is,
> > platform-independent code which provides
> > useful functionality for people coding
> > applications in C++.
>
> Well, py_cpp certainly fits that bill. Python
> is probably more portable, by any reasonable
> measure, than C++ itself.

Yes. The statement about Python, I agree with 100%. (The same applies to
many of the scripting languages).

My (mild) discomfort comes from a feeling that inter-language libraries/code
don't really "belong" to either language. I feel that Boost is C++ focused,
so that py_cpp doesn't belong. But the same reasoning says that it doesn't
belong in the Python groups, either.

It's probably precisely this issue that makes inter-language support so
patchy, in general. No-one is willing to give a home to the idea, so it
never flourishes. Witness extern "C" in C++. Clearly an attempt at
inter-language compatibility, but making it concrete and useful was seen as
outside the C++ committee's remit (from what I recall of the comments in
D&E). What happens with extern "fortran", or even extern "gnu C", extern
"borland C", etc...? It's probably true that Microsoft's __stdcall modifier
should really be extern "C,stdcall".

In that light, py_cpp is the conceptual equivalent of extern "Python". OK, I
can be persuaded on that.

> > In this context, inter-language libraries
> > are fraught with issues. We end up
> > inadvertantly taking sides in language wars
> > ("why does Boost support Python, but not
> > Perl/TCL/Ruby/Lua/...?"). We are also tied
> > into other software's versioning issues (does
> > py_cpp interface to Python 1.5, 1.6 or 2.0?).
>
> I agree with another poster that py_cpp can
> begin to provide a generic framework for
> interfacing with other dynamic languages. I
> also believe that inter-language interface is
> going to be one of those areas into which it
> will be important to broaden the scope of C++,
> eventually.

Inter-language interfacing is an area which *every* language needs to
address, at some level or other, if it is to survive. But it's an enormous,
and complex, can of worms. And it's very two-way. Can I write a chunk of
code in C++ and then use it from Python? Can I write a chunk of code in
Python and then use it in C++? At this point, I have to apologise, as I
haven't done my research and I do not know which of these problems py_cpp is
addressing.

The counter-argument is that C++ can already do this, via low-level code if
nothing else. But then again, the whole point of libraries is to encapsulate
the low-level nastiness.

I can feel myself being persuaded...

> > I'm not sure what you are implying in this.
> > Can I write a sockets program in C++ with
> > py_cpp and Python? I assume that the resulting
> > program would rely on Python, and hence would
> > not compile into a single distributable EXE?
> > None of this is bad in itself, but it reflects
> > back to the "is this appropriate territory"
> > question again.
>
> We haven't dealt with packaging issues with any
> other libraries at boost; I'm not sure why it
> should be a more important issue in this case.
> (?)

I'm not sure I see it as a packaging issue, per se. I was trying to express
a feeling that inter-language interfacing like this cuts through to the
basic issue of "what's a C++ program?"

But I take your point.

> > It's about the change from development to
> > support. Support doesn't mean stagnation,
> > but it does mean a focus on not breaking
> > compatibility for existing users.
>
> /What/ is about the change from development to
> support?

Sorry. That sentence means nothing to me on rereading it, either. Ignore it.

> It really depends whether you think that
> the general scope of the C++ standard will
> be limited for all time to generalized
> computational jobs and basic i/o. I believe
> that for C++ to survive and thrive, it will
> need to have a vastly expanded library,
> that begins to cover the same kind of
> territory as Java's or Python's library (see
> http://www.pythonlabs.com/pub/www.python.org/doc/current/modindex.html).
> Why do people decide
> to build their GUIs in web browsers with
> HTML/Java/JavaScript instead of C++ these days?
> There are lots of reasons, but the fact that
> there's no standard, portable C++ GUI is one of
> them.

Urk. I'll have to keep a very tight rein on myself here. Cross-platform GUIs
are one of my big hobby horses. I have very strong opinions that GUI
interfaces should conform 100% to the standard look and feel of the platform
on which they are running. Java (AWT/Swing) and TCL (Tk) are the two common
languages with portable GUIs, and in neither case do I feel that they do
this. (PLEASE don't ask me to expand on this, or you'll get a huge, highly
off-topic, and fairly unproductive message...)

Of course, other areas of these language libraries *are* good examples of
places where C++ could do with good library support. You could also look at
Perl's CPAN for more examples.

But are you arguing for copying those library designs in C++, or using the
existing code from C++ via inter-language hooks? (I can see both as
vluable).

> Just to prove that inter-language binding isn't
> too far afield, I'd like to point out that there
> is already a subgroup of the C++ committee
> working on a standardized SQL binding. Herb
> Sutter is leading the group.

I didn't know that. OK. That's a killer argument. I've been arguing for less
flexibility for Boost than the C++ committee allows for itself. Teach me to
be over-opinionated...

Paul.