Re: py_cpp

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-10-17 08:53:04

--- In boost_at_[hidden], "David Abrahams" <abrahams_at_m...> wrote:
> 
> ----- Original Message -----
> From: "Paul Baxter" <paul_baxter_at_i...>
> > Paul Moore wrote:
> 
> > > I've been watching the py_cpp messages go past, and while I 
don't want
> > to
> > > sound like I'm being negative for the sake of this, I wonder if 
this
> > is
> > > really appropriate for Boost?
> >
> > > Comments? I'm surprised that no-one else has said this - am I 
missing
> > > something fundamental from not having actually looked at py_cpp?
> 
> 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.
> 
> 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.

Then would it not be more appropriate to develop those missing areas 
in pure C++ code?

I really don't intend to criticize here, because the library is 
vastly important and useful to some people (I don't know python yet, 
so I'm not one of them, but I'm not letting my lack of knowledge here 
cloud what I'm saying).  However, I thought one of the major goals of 
Boost was to develop C++ libraries that through evolution and use 
might be considered with the next language standard?  If I'm right 
about that goal, py_cpp doesn't fit with Boost.  It's not possible 
for the standard to address multiple languages or gaurantee proper 
interaction between them, even if that's possible to do in the real 
world.  For instance, extern "C" is the closest thing we have to 
something like this in the standard today, and all it does is 
gaurantee no name mangling.  It's up to vendors to define what else 
this linkage might mean (i.e. parameter passing rules, etc.).  As 
pointed out on comp.std.c++ recently, it doesn't gaurantee that any 
given C compiler can link object code from any given C++ compiler 
generated with extern "C" linkage.  In practice we know this works, 
because OS vendors give specifications about all of this that 
compiler vendors (voluntarily) follow.  But those specifications are 
(rightfully) external to any language standard.

> > I had thought much the same, but since it is already in for 
review I
> > thought the point was moot.
> >
> > I also wonder whether it is too soon to review it (even if right 
for
> > boost) since previous messages have alluded to further changes in 
the
> > near future which sound a little more than problem fixing.
> 
> 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.

So long as the library is complete at time of submission then I agree 
that just because there's further extensions planned is not a reason 
to delay submission.  I hope to use a similar tactic with the Boost 
thread library, submitting a core set of features that will allow 
developers to expand into more complex concepts.
 
> > I thought the idea was to include a library and then over time 
establish
> > through usage what interfaces of code might require modification.
> >
> > It seems like once in Boost this library might still undergo 
significant
> > changes on a weekly basis. Perhaps I'm wrong on this, but previous
> > comments and added features during the review period have slightly
> > concerned me.
> 
> Is the concern that rapid improvements to a single library might 
cost boost
> some credibility?

I'd say that's a concern, but it doesn't lead to concluding that a 
library not be included just because extensions are planned.  What's 
important is that the extensions are carefully thought out and go 
through a seperate review period.
 
> > Having said all that, I'm chiefly on the sidelines and people 
like Dave
> > are an excellent driving force behind Boost. I certainly don't 
want Dave
> > to take these comments personally and do appreciate what looks 
like a
> > very useful library for both the python and C++ communities.
> 
> 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.

I hope the reason I gave is valid here, though I'm making an 
assumption about the goals of Boost.

Bill Kempf