Leading distributed object packages for python?

[Graham Dumpleton]

Syver Enstad <syver-en+usenet at online.no> wrote in message news:<usna1p1pj.fsf at online.no>...
> grahamd at dscpl.com.au (Graham Dumpleton) writes:
> > Somewhat related is OSE. Check out:
> > 
> >   http://ose.sourceforge.net
> 
> Hmm, looks cool. Especially that they seem to have focus on logging
> and other debugging facilities sounds interesting. But I get this knee
> jerk reaction when I see that it contains another container library
> for C++. Why the hell can't people just use the standard library, oh, well.

If you read the history for OSE posted on the web site you will see that OSE
actually predates the STL. OSE actually originated at a time when available
C++ compilers did not even implement templates. The provision of template
collection classes at that time was only possible because of a hacked up
version of a C preprocessor made available by Texas Instruments which did
some magic such that the proposed (at that time) C++ template syntax could
be used. It was a couple of years before the AT&T cfront 3.0 compiler with
template support became generally available. It was another few years after
that that the STL even became available in any sort of form, let alone being
standardised.

In that time, too much had already been developed within OSE, plus in other
projects which relied upon OSE, which used the existing collection classes.
It didn't make much sense to be ripping out five years of work which had
proven to be robust and easy to use, certainly easier to use and understand
than STL has proven to be. Frankly, to try and reimplement the upper levels
of OSE and host it on top of STL would be a nightmare, most likely taking a
few years and of course yielding something which could in no way be interface
compatible. In short not worth the effort. Such is the history of OSE. :-)