Re: [boost] py_cpp

From: Daniel Berlin (dan_at_[hidden])
Date: 2000-10-17 10:32:03

"Moore, Paul" <paul.moore_at_[hidden]> writes:

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

Given.
> 
> > >  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.
Python 3k doesn't exist yet.
We aren't tied into python's versioning scheme any more than we are
tied into the abi compatibility between different versions of C++
compilers (IE sun workshop 4.0 vs 5.0, not sun workshop vs gcc).

> 
> > > > 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.
Yup.
I'll get to why in a second.
> 
> > > 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?
Yes.
You could link it staticly against python if you chose.
> 
> 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.

I also embed python in various applications. Most I use a shared
library, but i have statically linked it, and it works fine.

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

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

Okay, well, let me explain my point.
My point is that most C++ applications of the future, or at least,
robust, extensible C++ applications (IE non-super domain specific must
run as fast as possible no exceptions are not what i'm talking about)
, will not be written purely in 
C++. Already they aren't. They all have their own scripting languages,
or use an existing one, and as time passes, more and more of the
application tends to be moved into a scripting language, because it's
a heck of a lot easier to work in.
(Now when i say python here, you could substitute your favorite
scripting language)
Given this, things like Python *are* the way of the future for
C++. Most of an application will be written in python, rather than
C++. Or at least, a significant amount of them will be in python.   
Whether this takes 1 year, 2 years, or 5 years to become the norm,
it's happening.
Having py_cpp in boost helps us provide for this future, since it is
the future of C++.

--Dan

> 
> Paul.