Python vs C for a mail server

Jens Theisen jth01 at
Sun Jan 29 09:31:00 EST 2006

Alex wrote:

> <>
> <>

> Since Robert Martin and Bruce Eckel (the authors of the two documents
> linked above) are both acknowledged gurus of statically typechecked
> languages such as C++, the convergence of their thinking and experience
> indicated by those documents is interesting.

Indeed, especially Eckels article shed some light about testing as an  
alternative to static typing. I still can't quite understand why you can't  
do both. Clearly unit tests should be part of any software, not only  
Python software.

Test failures, however, don't tell you anything about the current usage of  
your program - just about the inteded usage at the point where the test  
was writte. Clearly you can't test _anything_? And clearly you can never  
be sure that all you collegues did so as well? This not only about type  
safety, but simply name safety.

What do you do when you want to no if a certain method or function is  
actually used from somewhere, say "foobar", it a language which allows  
(and even encourages) that it could be called by:

getattr(obj, "foo" + "bar")()


There is no systematic way to find this call.

In C++, just commend out the definition and the compiler will tell you.

I'm pretty sure I red a PEP about static type safety in Python at some  
point. It was even thinking about generics I think.

> The "but without declaration it can't be self-documenting" issue is a
> red herring.  Reading, e.g.:

> int zappolop(int frep) { ...

> gives me no _useful_ "self-documenting" information

That's true. If the programmer wants to obfuscate his intention, I'm sure  
neither Python nor C++ can stop him. The question is how much more work is  
to write comprehensible code in one language or the other. I'm a bit  
afraid about Python on that matter.

Python provides ways to easy literal documentation. But I'd really like to  
have a way of indicating what I'm talking about in a way that's ensured to  
be in-sync with the code. Tests are not where the code is. I have  
difficulties remembering the type of a lot of symbols, and looking at  
testing code to fresh up usage is more difficult that just jumping to the  
definition (which the development envirnment is likely to be able to).

> [smart pointers and GC]

As you say, smart pointers are not full-blown garbage collection, which is  
usually what you want, isn't it? I my (admittedly short) life as a  
professional developer I have not yet come accross a situation where  
reference counting was not sufficient to model the memory management.

As for the locking: Apart from locking your whatever you need to lock in  
your user code, I don't think any special locking is necessary for the  
memory management. Smart pointer can increment and decrement their ref  
counts atomically as far as I know.

We use boost::shared_ptr in multi-threaded code just out of the box. We  
also use a reference counted string implementation in multi threaded code.

> At Google, we collectively have rather a lot of experience in these
> issues, since we use three general-purpose languages: Python, Java, C++.

I have no doubt that goolge know what they're doing, and if you're working  
there then you're likely to know what you're talking about.

I found it especially astonishing what you had to say against the use of  
smart pointers.


More information about the Python-list mailing list