RE: [boost] py_cpp

From: Moore, Paul (paul.moore_at_[hidden])
Date: 2000-10-17 09:44:02

From: Daniel Berlin [mailto:dan_at_[hidden]]
> "Moore, Paul" <paul.moore_at_[hidden]> writes:
> > 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/...?").
>
> Because nobody has submitted them for review. This would be a
> question for the FAQ.

You miss my point. I don't believe that we want people viewing Boost this
way (ie, I don't want such questions to be frequently asked).

> >  We are also tied into other software's versioning issues
> > (does py_cpp interface to Python 1.5, 1.6 or 2.0?).
> All of them.
> Python just works.

Python 3000? Again you miss the point. We are still tied into Python's
versioning issues, even if Python (so far) has a very good track record of
not causing problems on that score.

> > > 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?
>
> If you like.

Hm. I'm starting to think you are *trying* to miss my points.

> > I assume that the resulting program would rely on Python,
> > and hence would not compile into a single distributable EXE?
>
> This would be a bad assumption.

That's not entirely helpful. Do you mean that I would be able to build a
standalone program using py_cpp which did not rely on the Python DLL, or on
the Python standard library (script, DLL) files, being available on the
target machine?

Note, I do know Python - I have written extension DLLs for Python in the
past, and embedded Python into other applications. The resulting code has
always required a Python installation on the target PC. I'm aware of the new
distutils, but I believe that they produce an *installer* rather than a
single executable.

Also, the size of the Python distribution is an issue here, if we are
talking about using Python standard library code to augment a C++
application.

[[Note - I don't think that this issue is what py_cpp is for, and I don't
believe that Dave thinks that, either. But I felt that I should respond to
your unqualified comment. I don't think that it is worth pursuing this issue
any further.]]

> > None of this is bad in itself, but it reflects back to the
> > "is this appropriate territory" question again.
>
> Only if your assumption was correct, which it isn't.

I'm sorry, but am I missing your point here? I assume that you are trying to
argue that py_cpp *is* appropriate for Boost. While I am willing to be
convinced, you haven't offered me any concrete facts here, just
unsubstantiated denials of my points.

I repeat, even though I haven't looked into it in any detail (I have no need
of it myself) I think that py_cpp is a useful and valuable library. I just
question whether it fits with what Boost is aiming to provide.

Paul.