RE: [boost] py_cpp

From: Moore, Paul (paul.moore_at_[hidden])
Date: 2000-10-17 08:00:26

From: David Abrahams [mailto:abrahams_at_[hidden]]
> For the record, I have never had a clear idea of whether py_cpp
> is appropriate for Boost - as the first inter-language library,
> it certainly goes into uncharted territory for us. I asked the
> question many months ago when I posted the first versions of
> what I had done, but the group was silent on the topic.

I recall the posting. I don't think I (personally) understood the
implications of what you were saying at the time. Sorry. I see your point
that inter-language libraries are a valuable resource, and I take the point
that just because this is the first does not mean it is inappropriate.

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

In a similar manner to the C++ standard libraries, I see value in developing
a standardised interface for certain highly generic OS-dependent facilities
(like the iostreams facility). This should be handled with care and
restraint, so as not to rely on features which may not be available on all
platforms (I know some platforms don't even have a concept of IO - there has
to be a balance here). An example of this is the thread stuff. While a
generic threading library would be nice, we have to focus on the "standard"
and "cross-platform" aspects (and the consequent "minimal" aspect) -
otherwise we end up just picking one OS's approach and porting it to those
platforms we care about.

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

> One of the reasons I thought it might be a good thing to
> include at boost is that Python's standard library still covers
> a vast number of useful areas that std + boost do not.

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.

> I'm not sure that a library's review should be considered
> premature just because there is lots of room for
> expansion/improvement. In this case, one of the points of the
> review would be to get a feeling for which of the new features
> is most desired by potential users.

Agreed. I strongly believe that we should get things into the official Boost
distribution "as soon as they are ready". Stability has to be a part of
that, but also relevant are portability to as many compilers/OSes as
possible, usefulness, completeness of documentation, ...

Rejecting one library because it is likely to change, when we accept another
which doesn't run on half the C++ compilers out there, and another which is
barely documented, is unreasonable. Once a library is accepted, it will get
more users, and so there will inevitably be pressure to change things. This
is not a bad thing.

Also, review (and subsequent acceptance) imply a commitment to developing
and improving the library. Having a large number of libraries permanently
"under construction" but never complete is more damaging to Boost's
credibility than having released libraries undergo (controlled) change would
be.

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.

> Is the concern that rapid improvements to a single library
> might cost boost some credibility?

It's an issue, but no more so than the others I mentioned. Even the standard
library changed between versions of the draft. The key thing has to be a
visible stable goal, and progress towards it. OTOH, if a library is clearly
"alpha quality", then it should wait a while before acceptance.

> I'm not offended in the least, and am happy to leave that
> decision up to the group at large. That said, I think it is
> important that if we decide not to accept py_cpp, that we
> understand the criteria for making that decision, so we can
> make them part of boost policy. So far, the remarks I've heard
> do not clearly state what it is that would cause py_cpp to be
> deemed appropriate or inappropriate for boost.

Agreed. Clarifying this issue is very important. In my view, it affects not
just py_cpp, but also the threading discussions and probably other areas as
well (there was some talk of GUI libraries a long while ago).

As a general principle, I would argue that the basic benchmark would be "can
we imagine this library being accepted into a future version of the
standard?" On that test, I'd say that py_cpp would fail (and threads is
borderline). But this needs clarifying and tightening up before it is a
reasonable guide. (Assuming that the group agrees with me).

Paul