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

[David Abrahams]

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]

From: "Dave Hawkes" <daveh at cadlink.com>
> From: "David Abrahams" <david.abrahams at rcn.com>
> > > We must assume that atexit can not always be imported (may not be
> > possible
> > > in some applications).
> >
> > Really? Example, please?
> >
> If python is statically bound to an embedded application it may not have
> access to external libraries or access may be through a modified
__import__
> and we may not know the point in execution where it is configured.
>
>
> > > If the import fails it should not be fatal and we
> > > will have to let the user manually call the termination function.
> >
> > I guess that's OK, but I'm not convinced it's needed yet.
> >
> as above
> > > Maybe the user has to call an init function suppress the import?
> >
> > That sounds like an unneccessary complication to me.
> >
> 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.

[discussing what I'll call "Dave Hawkes' replacement for Python's eval()"]

> > > where a0,a1,a2 etc are succesive placeholders for the args.
> >
> > ;-) cute.
> > Well, you should use _1, _2, ... _9 for consistency with Boost.Bind and
> > Boost.Lambda.
>
> That can easily be done.
>
> > And you should templatize it so you can write:
> >
> >     call_statement("_1 += _2", o1, "freedom");
> >
>
> It already is!

cool!

> > > Any value
> > > assigned to rtn will be the return object (None otherwise). Multiline
> > > statements are supported.
> >
> > WHy not just return the result of the last line in the statement,
rather
> > than reserving a special variable name?
> >
>
> The return value could come from different code paths ie(trivial
example):
>
> if test:
>     rtn = 1
> else:
>     rtn = 2

How about wrapping all the code in a function body, so you can write
"return"?

> > If you must reserve a variable name, it should probably be _0.
> >
> Again, easily changed.

I'd prefer "return" to "_0 =" if possible.

> > If it's small and convenient I'll be happy to have it. However,
remember
> > that every new feature has to be documented, tested, and maintained.
You'd
> > have to be willing to do at least the first two for this one. If you
still
> > wonder whether it's appropriate, you might raise the question on the
> > c++-sig.
>
> I think its really useful to users embedding python as it make getting
small
> pieces of functionality implemented in python code almost trivial.

I totally agree. Just look at the number of tools out there which are
already trying to do something like this. This could be a major win for
interoperability!

> Documentation should be straightforward with the addition of a summary
and a
> good example. There are some plans in the works for testing, I'll email
> separately on that.

Thanks for all your work and new ideas!

-Dave