Re: Boost.Python copyright issues

Maciej (or should I call you Sobczak, as you once signed an email?),

Please make sure that Daniel Wallin is included in all email
regarding langbinding.  In fact, it would be better if we could
pursue this entire discusson on the langbinding mailing list.

[email protected]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding

Maciej Sobczak <[email protected]> writes:

> Hi,
>
> David Abrahams wrote:
>
>>>What will happen when one script sets the error (PyErr_SetString)? Can
>>> another script (in another interpreter) run without noticing it? 
>
>> IIUC, yes, but I'm not an expert in this department.  AFAIK, every
>> interpreter sees its own universe of objects.
>
>>>Can it also set its own error (another PyErr_SetString), so that I
>>> can examine each error separately?  
>
>> IIUC, yes.
>
>>>Is it possible to define separate sets of commands in different
>>>Python interpreters, but with the same command names, so that the
>>>scripts will not stumble one over another?
>
>> IIUC, yes.
>
> It's very surprising to me what you write. I went through great pains
> while trying to achieve something at least remotely similar to this
> and I cannot frankly say that I succeeded.

It seems to me that at the very least you can set sys.path differently
and then you'll automatically load different modules with the same
names in the different interpreters.

>>>Tcl needs separate approach, for the reasons mentioned above
>
>> I don't think so; Langbinding was designed to account for those
>> particular reasons.  There may be others, of course.
>
>>>(I can already point out a couple of assumptions in
>>>Boost.Langbinding that cannot be sensibly implemented in Tcl).
>
>> Please do!
>
> Well, with my library I do this:
>
> int fun1(/*...*/);
> string fun2(/*...*/);
>
> later:
>
> Interpreter i1, i2, i3; // separate interpreters.
>
> i1.def("fun1", fun1);
> i1.def("fun2", fun2);
>
> i2.def("fun", fun1);
>
> i3.def("fun", fun2);
>
> string s1 = "some script that sees both fun1 and fun2";
> i1.eval(s1);
>
> string s2 = "some script that sees only fun pointing to fun1";
> i2.eval(s2);
>
> string s3 = "some script that sees only fun, but pointing to fun2";
> i3.eval(s3);
>
> The important thing is the interpreter name that prefixes "def" (and
> "class_") and "eval". This is a regular object-based interface.
> I do not see how something like this can be achieved with
> Boost.Langbinding, without resorting to either "singletonizing" the
> interpreter (ouch!) 

We're not doing that, and...

> or emulating artifical scopes in which def and class_ are supposed
> to operate (ouch!).

... I don't know what "emulating artifical scopes" means, but it may
not be as painful as you assume.  We have already prototyped most of
these things, and the interface used in Luabind already works quite
well with basically identical requirements.

http://luabind.sourceforge.net/docs.html

> Do you have some specific solution in mind?
>
> BTW - Tcl has also another nice feature, it is called a "safe
> interpreter". Any interpreter can be turned into a "safe interpreter"
> with a single function call and from that time the interpreter will
> "forget" all builtin commands that are related to files, network,
> process control, etc.
> Simply - a sandbox where no damage can occur.

That's nice, but it has no bearing on the viability of Langbinding.

>>>On the other hand, Tcl is way much simpler than Python. For
>>>example, a function cannot differentiate its parameters between 7
>>>and "7", so there is no way to implement function overloading (at
>>>least on the parameter type).
>
>> I have a hard time believing that *no* type information is available
>> at runtime.  If everything is a string in Tcl, you can at least parse
>> the strings to figure out types.
>
> Not exactly. You can ask the interpreter to parse the data to some
> destination type, but in the case of "7" you will succeed with queries
> for all supported types (string, int, long, double and bool).

But not for many user-defined classes.  I assume you _are_ going to
support wrapping of C++ classes somehow...?

> Of course, it is possible to always ask for a string and later try to
> discover what was meant (so - what was meant with "7"?), but that
> would be... err... doing a lot of work which is simply not needed -
> nobody overloads in regular Tcl

Nor in regular Python.

> so there is no living culture and tradition and therefore no
> audience that would benefit from this feature.

I disagree with your conclusion.  Nobody had overloading in Python
either, but it's very much appreciated that a C++ interface that
includes overloading can be exposed to Python in a fairly transparent
way.

> The approach I took is that I know the destination type (I get it from
> the function type) and I request the interpreter for this type. If it
> cannot succeed, the error state is set (when calling from Tcl) or the
> exception is thrown (when calling from C++).

That's just a very crude version of what Boost.Python does (and an
even more crude version of what Luabind does).  There's no reason the
Langbinding facilities couldn't be very beneficial here.

> Interestingly, internally, everything is manipulated as "object"
> (similar to Python), but the exact representation is set when
> requested and cached for subsequent requests, so that there is no
> recurring parsing penalty when, for example, some object participates
> in a long arithmetic expression or is repeatedly used as a parameter
> to some string-related command.

How can you know when the cache needs to be invalidated?

>> Interesting.  Not that it affects the viability of langbinding, of
>> course ;-)
>
> Sure! :)
>
> In the same way, I do not think that my attempts at cpptcl are
> pointless. 

I never said they were.

> It is a specialized library to do what I always wanted to
> do on the border between C++ and Tcl, exploiting all Tcl goodies.

More power to you.

Our aim with langbinding is to factor out the commonality between all
such libraries (and there is very, very much!) so that your job is
reduced, mostly, to figuring out how to "exploit all Tcl goodies."

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8