Re: [boost] py_cpp

From: Paul Baxter (paul_baxter_at_[hidden])
Date: 2000-10-17 12:21:35

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

My, perhaps incorrect, view is that much of what is in Boost might be
considered for an extended standard library.

I personally don't think py_cpp falls into this category as it isn't
sufficiently general. (more below)

> > I also wonder whether it is too soon to review it.
>
> 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.

That's the point though. I don't think that 'getting a feeling ..' is a
major part of the review process or subsequent usage.

I would hope that this happens whilst being refined in the vault and
through preliminary usage by several types of python user.

Discussions with the python community at large seem to still be in the
early stages.

It may be that this library has been used for months by several types of
python user prior to this review and I am just not aware of it. Has it?
Certainly recent updates imply that some features are relatively new.

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

Issues of suitability to Boost aside, my concern is that the process of
review (as I understand it) is to present, at a minimum, a good stab at
defining interfaces after initial discussions have taken place.

It is not clear to me that py_cpp has been refined and used enough to
warrant such a review. It is not heavily based on prior-art nor had
extensive usage.

I'd have thought that even in Boost's vault, the discussions here would
be a valuable adjunct to the main discussions in the python community as
it uses the library. Why does it need to be reviewed and incorporated at
such an early stage in its development?

And yes, at such an early stage in development it could set a precedant
that harm's Boost's library.

> In general I wouldn't expect discussion of py_cpp to dominate the
boost list
> the way it has during the review period, but maybe you're referring to
> something even more fundamental?

I do have a few personal doubts whether it belongs under Boost's
auspices, but am not overly concerned because Boost is still finding a
direction and I am not the navigator, just an interested bystander.

What I find strange is that it is during the review period ( I
understand this to mean that the library is close to a final interface),
far-reaching discussions with the python community are still taking
place.

One example is the overlapping functionality between py_cpp and CXX.

It seems that using python for high-level and C++ for low-level may well
be highly desirable, and yet you seemed to imply that is something that
hasn't been widely user-tested yet in py_cpp.

In response to Ted Milker's enquiry a few days ago, you wrote 'It isn't
well-documented yet, but py_cpp can be used for this purpose.'.

In the same response you also suggest that CXX might currently be better
for Ted's purpose.

Could the library benefit by refining this aspect a little longer so
that it matches or surpasses CXX in terms of flexibility,
maintainability and ease of use?

I have no doubt, irrespective of whether it ends up in boost, that this
will be a key feature for a lot of C++ and python users alike.

Unfortunately I am not knowledgeable enough in python to provide such a
review.

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

Agreed.

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

My reasoning for it being inappropriate is that it seeks to solve a
specific interfacing difficulty with one language rather than a more
generalised issue of say interfacing with ANY or a subset of other
languages.

I am not arguing whether such a generalised approach is feasible, but I
would see Boost's content as more generic.

The standard library, for instance, puts forward the general container
and iterator concepts before providing a specialised set of containers
etc.

In much the same way I would hope that Boost members would discuss what
concepts, patterns of usage etc are required before embarking on a
specific inter-language library even if it is in the context of a python
interface.

The current discussions regarding callbacks might well be one general
concept that becomes a piece in such a puzzle.

Note that I understand the need for specific language implementations
first before generalisations can occur, but it is those generalised
concepts that I think should provide the foundations of any such library
in Boost.

Throughout this, I hope it is clear that I am very impressed with py_cpp
and do wish to devote some time to using it in the near future.

I am impressed with the effort Dave, Ullrich and others have put into
the library but do not feel comfortable with its inclusion in Boost.