[PYTHON C++-SIG] LLNL Python/C++ integration: current status

[Geoffrey Furnish]

Catching up on some email traffic that hit me in a cruch last week.

Barry A. Warsaw writes:
 > 
 > First an aside: I have not tracked C++ developments very closely since
 > coming here to CNRI about 2 1/2 years ago, so I'm only dimly aware of
 > details of the new features like RTTI, exceptions, and namespaces.  I
 > used to have one of the earliest editions of the ARM.  Would you
 > recommend getting a new edition, or is there a better reference manual
 > I can get to bone up on these features?

I'm not a language lawyer, so the actual ARM hits me pretty dry.  I
have found, however, that Stroustrup, "Design and Evolution of C++" is
extremely readable, and provides good discussion of the rationale for
the fatures which have shown up in the language, as well as detailed
discussion of many of the proposals which were rejected, and /why/
they were rejected.  Very little will give you the breadth of coverage
of C++ that D&E provides.

Other stuff:  We recently bought a bunch of copies of Scott Meyer's two
books, "Effective C++", and "More Effective C++", and passed them
around to all members of our team.  I have found both of these to be
really excellent.  Another excellent choice is the "C++ FAQ" by
Marshal Cline.  He hits /lots/ of the pragmatics which go
understressed in much of the C++ literature.

 >  > 3) Introducing C++ classes for the various major Python abstractions,
 >  >    such as dictionaries, lists, tuples, modules, etc.
 > 
 >     GF> Python really look this way to the C++ programmer.  Planned
 >     GF> classes at this time include:
 > 
 >     GF> PyDict
 >     GF> PyList
 >     GF> PyTuple
 > 
 >     GF> and possible also PyArgs,
 >     
 > I'd only suggest adding the word `Class' on the end here, (or maybe
 > `Wrapper') e.g. PyDictClass.  Although `PyDict' may never conflict
 > with other names in the C API, there are symbols like `PyDict_Type'.
 > It seems like it could cause confusion, for example, what if you
 > passed a PyDict object to PyDict_Type?  That would seem to me a
 > natural thing to want to do given the naming.

I haven't looked at that exact function yet, but I am imagining that
it will be shadowed by a a method in PyDict.  so you wouldn't actually
"pass a PyDict to PyDict_Type".  Instead you would "invoke the method
Type() on a PyDict".

	PyDict *ed;
	d->Type();

Also, all the C++ stuff is going to live in a namespace, so actual
name clashes should not be a problem.  I am a little bit inclined to
jus go ahead and drop the Py prefixes, since they will all live in a
namespace which will probably be named Py.

-- 
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
_______________