Python wrapper for C++ STL?

[shindich at my-deja.com]

In article <90t9n902p8r at news2.newsguy.com>,
  "Alex Martelli" <aleaxit at yahoo.com> wrote:
> "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
>
> "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.

Regards,

Alex Shindich
Visit http://www.shindich.com/


Sent via Deja.com http://www.deja.com/
Before you buy.