does opensource move faster with python?

Ken Seehof kens at sightreader.com
Mon Feb 28 10:23:14 CET 2000


Michal Wallace (sabren) wrote:

> Does opensource move faster with Python?
>
> I just surfed over to the GnuCash website. I've been waiting quite a
> while for a "real" release.. But it never seems to come.. Same thing
> with Mozilla.... I'm not trying to rag on them.. But I have to wonder:
> would development move any faster using Python to prototype these
> tools? That's the claim I keep hearing about python.. But how come
> more of the free software world isn't using it?

Momentum.  Safety in numbers.  Fear.  But most of all, C/C++
programmers don't have any spare time to learn anything new.

In any case, python numbers are growing exponentially.  There's
a new book about every month, and the IPC8 python conference
had double last years showing.

> ARE there projects out there using python as a prototyping language
> with the possible intention of discarding it eventually and rewriting
> in C?

I doubt it, though it would certainly be possible.

I can't think of any situation where I would use python purely as a
prototyping language, and then discard the python.  Except in very
unusual cases, there really isn't any disadvantage in a final product
being written in multiple languages.  On the contrary there are many
advantages.  In fact, I often take a perfectly good C program and
-add- python to it!

The python development scenario goes something like this:

1. Wrap existing c libraries in python (usually this has already been done)
2. Write the application in python
3. Replace performance critical elements with C (wrapped in python)
4. Continue using python for the framework

Note that step 3 will generally involve a very small percentage of your
code, since 98 percent of CPU time is usually spent in 2 percent of the code.

The only thing I can think of that I wouldn't write this way is a hardware
driver.

Remember the previous generation:

1. Wrap assembly hardware control routines in C.
2. Write program in C
3. Replace performance critical elements with assembly (wrapped in C)
4. Continue using C for the framework

Not "prototype in C and rewrite the whole thing in assembly" unless
your target is a chip that you don't have a C compiler for.

The whole process goes 4 to 7 times faster in Python than in C or C++
depending on whose estimates you look at.  My measurements have
indicated only about 4 to 1 development speed improvement, but that
was after 12 years of C++ experience and about 2 months of Python
experience.  I'm sure the ratio has increased for me since then but I
haven't had an opportunity to measure it.  However, I have gained some
insight about where the boost comes from.

Think about where your time goes when you write a program.

The interactive interpreter tightens the development loop and gives instant
feedback.  Unit testing is trivial.  Much less tendency for bugs to appear
(almost all memory and type related bugs just don't happen, dispite purely
academic concerns about Pythons lack of static type checking). Much
easier to find bugs too, even when they are in the C components.

> Cheers,
>
> - Michal
> -------------------------------------------------------------------------
> http://www.manifestation.com/         http://www.linkwatcher.com/metalog/
> -------------------------------------------------------------------------

Enjoy,

- Ken





More information about the Python-list mailing list