Python 'Lets Me See The Forest'

David Bolen db3l at fitlinxx.com
Mon Jun 7 17:52:02 EDT 2004


"beliavsky at aol.com" <beliavsky at 127.0.0.1:7501> writes:

> I am no C++ expert, to put it mildly, but couldn't some of your
> problems have been solved by using C++ instead of C? C++ has data
> structures like vectors, lists, and maps, with many algorithms in
> the STL to work with them.  Using references to pass arguments, one
> can avoid low-level pointers in many cases. C++ strings are easier
> to use the C char's. There are templated classes to replicate some
> of the functionality of Python's Numeric/Numarray or Fortran 90/95
> arrays. C is more of a low-level systems language than an
> application programming language -- comparing it to Python seems
> unfair to me, when the choice of C++ exists.

I don't know if it's just me, but a funny thing I've found is that
after using Python almost extensively for the past 4-5 years, I find
it much easier to grasp and appreciate the C++ STL than I did prior to
Python.  Of course, to be fair back before Python when I was using C++
more significantly, I hadn't really been out of the C world for too
long, and I recall compiler template support being more hit and miss
so trusting the STL (if it was even available) was tricky, but I think
Python helped get my mindset more acclimated to the higher level data
constructs, making it more natural to use their C++ counterparts when
working nowadays with C++, things which I tended not to utilize as
effectively in the past.

With that said, doing similar work in C++ versus Python even today
feels like I'm working in a tar pit while working on the C++ side.
Oh, I like the performance and part of me still can't help but enjoy
the feeling of working closer to the metal, but egads, the extra
typing (particularly with the STL), the fighting with the compiler's
type checking, those horrible template error messages.  Heck, basic
iteration, or even the hoops to jump through to bind instance members
for callbacks.  The STL is a valuable set of generic containers and
algorithms that I wouldn't want to do without in C++, but similiar to
the original poster's point, I still feel burdened down with details
when working with them compared to equivalent Python code, even when
the code is algorithmically and data structurally similar.

Of course, the end performance advantage of the C++ version over the
Python version makes up for that in some specific cases, but not
enough for me to ever want to go back to C++ as a language of first
choice for most of my target development, even with the STL, strings
and other templated classes.

-- David



More information about the Python-list mailing list