[C++-sig] Conversion of python files to C++ ostreams

[troy d. straszheim]

Ravi wrote:
> Hi Troy,
> 
> On Sunday 04 April 2010 16:16:46 troy d. straszheim wrote:
>> The boost.python code behind this is 
>> in a separate repository, here:
>>
>>    git://gitorious.org/~straszheim/boost/straszheims-python.git
>>
>> The code has diverged quite a bit  from trunk boost.python by now.
>> I was only playing with your use case, tossing my results out there. 
>> Ravi and I discussed the as<...> interface at length on this list some 
>> time ago, and I've recently resumed playing with it.
> 
> I am quite concerned about the divergence. How could I help integrate your 
> changes back to trunk? As far as I am aware, neither Dave A nor RWGK have 
> expressed any interest in these changes, and I am worried that all this work 
> will be for nought. You are doing quite a bit of work with boost.python but I 
> am worried that everything will stay as patches (sort of like Niall Douglas' 
> thread-safety patches).

Your concern is quite justified, IMV.  At this point it is way beyond 
patches, we're in to the thousands of lines of code, throughout the 
library and testsuites.

The first main change was to gut a bunch of the old preprocessor gunk 
and replace with boost.fusion.  This would make my branch incompatible 
with Niall's threadsafety changes;  on the other hand, it would probably 
be much easier to implement them.  as<...> and scored overload 
resolution are built on top of the fusionization stuff.   I've removed a 
great many old workaround #ifdefs.

Off the top of my head, there are several significant problems:

* MSVC can't compile the fusionization: I tried briefly to get it 
through but am not familiar enough with this compiler to figure out how 
to trick it in to doing the right thing.

* None of it is integrated with boost.build:  the branch builds against 
any boost >= 1.38 or so.  It uses CMake.

* The testsuite has been completely overhauled to work on python 2 and 3 
without that nasty 2to3 business that came with the original py3k 
patches.  valgrind is integrated.  I found a few odd py3k bugs in the 
process IIRC.  None of this has been boost.buildized... it uses CTest.

* This new overload resolution and as<...> business isn't documented, 
and hasn't been really stress-tested.  The current docs are of uncertain 
origin and difficult to deal with, the whole business needs overhauling.

There is probably more less major stuff.

There are various bugfixes on svn.boost.org that are marked '[fix in 
git]', with links to my git commits, those probably could be simply 
applied to boost svn.  The stl_iterator was one of them I think.   I 
caused some confusion with these markings,  I plan to remove them and 
track this information separately.

One possible plan would be:

- Call this branch boost.python v2.1 or v3 or something

- Figure out what else should go in there, e.g.

--- Niall's threadsafety patches
--- the recent std::ostream& stuff
--- better indexing suites (I have an improved map_indexing_suite 
sitting around that should go in)
--- maybe some of your numpy stuff?
--- things laying around on various wiki pages
--- docs, docs, docs
--- examples, examples, examples

- Get all that implemented separate from boost trunk, beat on it at 
length, including having "power users" actually try it with their 
production apps:  py++, TnFOX, my physics stuff, etc.

Then boost.buildize and commit wholesale back to trunk.   That's my two 
cents, anyway.

In any case I'd love to have you play with the code.  Hopefully you're 
familiar with git and cmake...

-t