Python vs C for a mail server

[John J. Lee]

"Randall Parker" <techiepundit at futurepundit.com> writes:
[...]
> The code I'm writing in Python is a test executive to test embedded C
> code. Then tests get written in Python that the test executive
> processes. No, I'm not going to write yet another layer of tests in
> order to compensate for shortcomings in the Python language.

Yeah, despite being a fan of test-first, I don't write tests for tests
either.  That has been true when I've been testing numerical code
written in both C and Python, for example.  If I were writing any sort
of test infrastructure code, however tiny, I would write tests for
that code, regardless of the language.  For those reasons, I don't see
writing tests as compensating for shortcomings of Python.

This discussion reminds me of statistics books that claimed that, just
as a measurement without an error estimate was meaningless, so an
error estimate without its own error estimate was also meaningless.
By that logic, seems all measurement is meaningless :-) (please
everybody note this is meant as a mildly amusing aside, not a point of
argument!)


> > It's also a pain to write unit tests, but it's much more rewarding
> > than writing type declarations. Not only does it force you to think
> > through the ramifications of changes, but you also document your
> > intentions through your tests.
> 
> I do not have time to write unit tests for the Python classes. I  have
> plenty of unit tests to write in Python for the embedded C modules.
> When I run and hit a problem in Python I just  debug it and fix it.
> That's a lot faster than writing unit tests.

As somebody who has worked in both test-first and 'a smattering of
tests' styles, I'm quite sure you're right: when you don't have lots
of unit tests, writing them slows you down.  The benefit to be had
comes when making *changes* to code with *good* unit test coverage.
We all know people whose 'pragmatism' sometimes operates on, um, a
strictly local basis and neglects the impact on a wider scale.  I
think we usually fall into that trap when we fail to write unit tests.

I'm open to the idea that the benefits depend heavily on the sort of
code you're writing, though.


John