Python wrapper for C++ STL?

shindich at shindich at
Sat Dec 9 15:24:16 EST 2000

In article <90t9n902p8r at>,
  "Alex Martelli" <aleaxit at> wrote:
> "Greg Jorgensen" <gregj at> wrote in message
> news:KVjY5.126920$U46.4261650 at
> > <shindich at> wrote:
> >
> > > I am not saying that there is any point in wrapping STL for
Python. All
> > > I'm saying is that STL can be used to write C++ extensions that
> > > implement specific algorithms.
> >
> > Sure it could, though C++ + STL = C O D E  B L O A T, so using that
> Naah...!  It depends on your general setup.  I regularly use MSVC++6
> a top-of-the-league optimizer -- wish I could use KAI...) with ATL and
> to
> build truly tiny COMponents -- no reason the footprint should be any
> with a similar setup, to build Python-specific extensions (of course,
> COMmie
> can be used both from Python and from other languages, and you do have
> ATL infrastructure already tuned and optimized for it -- but, alas, it
> cross-platform yet, at least until XPCOM should mature a bit...).
> > for Python modules will likely suck up a lot of memory. If you want
> > data structure Python doesn't have--sorted associative containers,
> > example--you'd be better off writing a module in C to implement just
> > rather than try to press the STL into service where it won't give
you any
> > benefit.
> I consider high programming productivity to be a very significant
> (or else, I wouldn't be using Python!-).  If using C++ (and the
> C++ Library, or even specifically STL if I must -- there's a
> halves my development-effort (and the productivity benefit is often
> than that), I'd be quite willing to take a small performance hit (e.g.
> terms of footprint), IF I had to -- and I noticed that I often don't.
> I consider it pretty sad that I still have to code Python extensions
in C,
> rather than C++, to ensure they're "taken seriously" by the Python
> community, actually.  I'll do it when I must (as I'm doing in gmpy),
> it *IS* a sad reflection on the state of the Python world:-).  Oh
> at least it can be 'full ISO C' (commonly still mis-called ANSI C:-)
> days -- meaning the standard of 1989, of course (we wouldn't want to
> be TOO modern, now would we?-).
> Alex
> "STL = C O D E  B L O A T" - this is so last century!
Compilers/optimizers produce quite efficient code now days. I agree with
Alex that templates, and template libraries such as STL , ATL, etc.,
improve productivity significantly!
And I am all for going away from "C" standard! Unfortunately, C++ is not
a binary standard. For instance, there is no standard on how "this"
pointer is to be passed to the instance methods. This means that there
has to be a preffered compiler for each platform, because compiler
manufacturers are free to pass "this" pointer any way they like.

This is not going to be a problem under .NET. But unfortunately,
Microsoft's moto is "Any language, Microsoft OS." I really wish there
was a good alternative to Microsoft's .NET. And please don't start me on
JVM will save the World! I am talking about an open CLR (common language
runtime), that will not limit languages the way .NET's CLR does, but
will be expandable to accomodate features of any language, yet provide a
good basis for interoperability.


Alex Shindich

Sent via
Before you buy.

More information about the Python-list mailing list