[C++-sig] Re: boost::python::api

[Dave Hawkes]

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:0d9d01c2281d$e9de2e50$6601a8c0 at boostconsulting.com...
> cc:'d to C++-sig - this conversation should be moved there.
>
> [discussing how to release objects which are currently made immortal by
the
> library before PyFinalize is called -- needed for Python embedding]
>
> > Maybe, but it's probably not a lot of additional code over and above
what
> > would be required anyway.
>
> Hmm, I'm beginning to think that since an embeddor needs to explicitly
call
> Py_Finalize(), it's not too much to ask him to call our finalizer first.
> That would make the atexit question moot, and individual developers who
> need that functionality could implement it. It would also obviate the need
> for a special init() function which suppresses the atexit stuff. Much
> simpler.
>
I think that is acceptable, the user could even use the atexit module
themselves to achieve this end.
(a simple call_statement use maybe!)

> [discussing what I'll call "Dave Hawkes' replacement for Python's eval()"]
>
> >
> > if test:
> >     rtn = 1
> > else:
> >     rtn = 2
>
> How about wrapping all the code in a function body, so you can write
> "return"?
>
The idea was to give the user more room to manouver than eval/exec provides,
while still enabling the python code to be kept as simple as possible. This
just seems to be giving the user additional restrictions on how the code is
structured. If we have a fixed set of variable names going in as arguments
it doesn't seem to be that illogical to have a fixed variable name for the
return value as well.

Also wrapping in a function body will incur additional overhead as I think
the only way I can get a variable back from exec is through the local
dictionary anyway.

Additionally I am probably going to have to provide an additional argument
to call_statement to specify whether the python global namespace should be
polluted by the call or not.

> > > If you must reserve a variable name, it should probably be _0.
> > >
> > Again, easily changed.
>
> I'd prefer "return" to "_0 =" if possible.
>
As above. I think we should stick to a return variable, whatever it is
called.

Dave Hawkes