Re: [boost] py_cpp

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-18 13:58:06

----- Original Message -----
From: "Paul Baxter" <paul_baxter_at_[hidden]>

> 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 disagree. You might ask Jeremy how much change occurred in the Graph
library based on user feedback during the review period.

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

Your impressions are all correct.

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

There is precedent for this in boost, though. I believe that when they were
originally submitted, array, compose dir_it, functional, timer, operators,
and compressed_pair were also new libraries without extensive prior art or
usage. Don't shoot me if I'm wrong on one or two of these ;-)

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

It doesn't need to, but it might be useful. On the other hand, even some
people in the Python community would rather see this library hosted in a
more Python-oriented location. It's not at all clear to me why that makes
more sense, though. This library straddles the border between the two
languages. Note that py_cpp requires boost. Python people could equally well
complain that py_cpp requires more than Python plus a C++ compiler ;-).

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

I expect those to go on for some time. The better-supported py_cpp is, the
more discussion I expect to take place. Participation is usually
proportional to interest and usefulness.

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

Not at all. It was the inverse, which I think is probably much less useful,
that hasn't been widely tested with 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.

It might.

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

Probably integration with or subsumption of some parts of CXX would be the
best approach in the long run. I contacted the CXX maintainer about this
long ago. He was interested, but since then I don't think he's had much time
to address it. I think as py_cpp gains acceptance and influence it will be
harder to ignore ;-)

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

Well, I think my approach of using template argument deduction to decode
function signatures and define argument/return type conversion is certainly
generalizable. On the other hand, I freely admit that trying to provide a
high-quality language binding to more than one language is beyond my ken.
That said, I don't see why a generalized binding should be neccessary for
boost acceptance of such a library.

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

It also contains at most 2 versions of the sin() function. It (wisely) does
not attempt to generalize everything.

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

Fair enough.

-Dave