[PYTHON C++-SIG] Re: LLNL Python/C++ integration: current status (fwd)

[Geoffrey Furnish]

Johann Hibschman writes:
 > However, I would like to see enough cooperation and awareness of the
 > compiler issue to consider containing uses of things like member function
 > templates and RTTI code to discrete portions of the code.  Those discrete
 > portions can then be worked around with elaborate hacks by the
 > compiler-challenged. 

The direct invocation of C++ member functions should work with an
compiler at the level of Cfront 2.1 or better.  I know of only one
computer in the world where the situation is still this bad (name
withheld to protect the guilty).

However, the argument parsing in our plan uses member templates.  I
could imagine a non-member template plan working something like this:

template<class X1, class X2>
void PyArgs_ParseTuple( PyArgs *args, X1& x1, X2& x2 );

You would then do something like:

PyArgs_ParseTuple( args, x1, x2 );

instead of what we will do:

args->ParseTuple( x1, x2 );

This would rely on only regular templates, not member templates, and
would help people get through the pinch for a while.

The traits technique in principle is not beyond the capability of
Cfront, but the new-style specialization syntax is not known by
Cfront.  Not sure what to say about that.  I'm not sure if there is a
way to state template specializations which is admissible under both
the new ANSI standard and under the old ad-hoc conventions.  A
language lawyer I am not.

 > I don't know your code, so I don't know if this is already true, if this
 > is nigh-impossible, or if this is possible with minor adjustments.

It's hard for me to say.  I think it will be necessary for people who
want workalikes for nonconformant compilers to spend a little time
working up the files to provide the alternate mechanisms.  When
someone tries this, they can tell the list whether it was merely
annoying, or practically death-defying.

 > I'm still climbing the C++ learning curve.  I just looked into STL
 > recently and was struck by the similarity of the feel of their
 > standard classes to the standard Python data structures.  If some
 > of the template-intensive code can be replaced by STL calls, then
 > end-users could simply use whatever STL implementation they may
 > have at their site.  That would confine some of the portability
 > problems to a well-defined library which has probably already been
 > ported.

One way of reading this would be to think of trying to build an STL
adaptor to a PyList, or some such.  I have thought of that too, but
have not acted on it.  We are still learning the STL techniques here,
and so could still use suggestions.  Since we plan to make classes to
wrap the Python C API anyway, it seems like the most obvious plan is
to simply build these classes with iterators which obey stl-like
semantics.  But until there are some sample implementations of the
various competing ideas, it will be hard to pass judgement on the
quality of the various approaches.

 > Personally, I was thinking about gradually implementing a STL-to-Python 
 > conversion, as I needed it in the code I'm writing for my own use.  Does 
 > anyone think this is a good idea?  If not, why not?

Can you define this more precisely?  I can't quite tell what you mean.

-- 
Geoffrey Furnish		email: furnish at llnl.gov
LLNL X/ICF			phone: 510-424-4227	fax: 510-423-0925

_______________
C++-SIG - SIG for Development of a C++ Binding to Python

send messages to: c++-sig at python.org
administrivia to: c++-sig-request at python.org
_______________