Python wrapper for C++ STL?

[Alex Martelli]

"Greg Jorgensen" <gregj at pobox.com> wrote in message
news:KVjY5.126920$U46.4261650 at news1.sttls1.wa.home.com...
> <shindich at my-deja.com> 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 combo

Naah...!  It depends on your general setup.  I regularly use MSVC++6 (hardly
a top-of-the-league optimizer -- wish I could use KAI...) with ATL and STL
to
build truly tiny COMponents -- no reason the footprint should be any larger,
with a similar setup, to build Python-specific extensions (of course, a
COMmie
can be used both from Python and from other languages, and you do have the
ATL infrastructure already tuned and optimized for it -- but, alas, it ain't
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 some
> data structure Python doesn't have--sorted associative containers, for
> example--you'd be better off writing a module in C to implement just that,
> 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 benefit
(or else, I wouldn't be using Python!-).  If using C++ (and the Standard
C++ Library, or even specifically STL if I must -- there's a difference!-)
halves my development-effort (and the productivity benefit is often more
than that), I'd be quite willing to take a small performance hit (e.g. in
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), but,
it *IS* a sad reflection on the state of the Python world:-).  Oh well,
at least it can be 'full ISO C' (commonly still mis-called ANSI C:-) these
days -- meaning the standard of 1989, of course (we wouldn't want to
be TOO modern, now would we?-).


Alex