[C++-sig] Re: [BPL] python::interpreter proposal

Bjorn Pettersen BPettersen at NAREX.com
Fri Jan 3 20:35:05 CET 2003


> From: Nicodemus [mailto:nicodemus at globalite.com.br] 
> 
> Bjorn Pettersen wrote:
> 
> >>Nicodemus wrote:
> >>They're equivalent to the "exec" statement and to the 
> "eval" builtin 
> >>function in python.
> >>
> >That's essentially what I ended up with, although I have the 
> >global/local dict be persistent with the interpreter (i.e. you don't 
> >pass them in). Making them optional would probably be most 
> >convenient/flexible.
> 
> Agreed. You have working code for this already?

For our needs, certainly <wink>. It's really not a lot of code... let me
know if you want to have a look...

> >I ended up making exec return an int so that we could do:
> >
> >  int foo(int x) {
> >      static int ok = py::exec(
> >          "def foo(y):\n"
> >          "    return y**y\n");
> >      return py::extract<int>(py::fn("foo")(x));
> >  }
> >
> >(i.e. only calling exec once).
> 
> You mean exec returning an int to describe success or 
> failure? I would 
> prefer an exception in case of an error, and returning void.

No, the point was being able to declare the int static so py::exec() was
only called on the first call to foo() -- and throwing an exception when
something bad happens. No use wasting cycles re-executing the function
definition every time... If someone has a more graceful suggestion I'm
all ears :-)

[evalBlock description...]
> 
> Sorry, but I didn't quite understand, how the script returns 
> this value? 
> Could you post a simple example of such a script? Just curious. 8)

The script would look something like:

  x = foo(y)
  x += bar(y)
  x

i.e. the value in x should be returned. We call it as:

  py::set("y", cppYObject); // assign our c++ object to variable 'y'
  int result = py::extract<int>(py::block(theCodeAbove));

On a not completely related note <wink>, it was mentioned on c.l.py
recently that the multiple interpreter functionality isn't implemented
enough to be useful, so it might be better to focus on a single
interpreter for now...

hth,
-- bjorn















More information about the Cplusplus-sig mailing list