Python vs C for a mail server

[Jay Parlar]

> 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.
>
You can do both, but why? *Especially* in a language like C++, where 
thanks to pointers and casting, there really isn't any type safety 
anyway. How much time in your C/C++ code is spent casting and trying to 
trick the compiler into doing something that it thinks you shouldn't be 
doing?

> 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.
>
How does type safety tell you anything about the current usage of your 
program? All static types can tell you is what the input/output types 
should be, and in no way show any semantic relationship between actual 
output and the input. Tests can do that.

And unit tests *might* not tell about the current usage, but 
integration tests certainly do.

> 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 don't think I've ever seen anyone advocating calling a function like 
getattr(obj "foo" + "bar")(). You can do some very powerful things with 
getattr, thanks to Python's dynamic nature, but I don't think anyone is 
recommending calling a function like that.


> 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.
>
And is that fear based simply on "feeling", or on actual experience. 
Because in all of my own industry experience, it's been MUCH easier to 
jump into someone else's Python code than someone else's C++ code (and 
at my last job, I had to do a lot of both). I find Python to be much 
more self-documenting, because there's not so much scaffolding all over 
the place obfuscating the true intention of the code.


> 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).
>

You need to look at doctest: 
http://docs.python.org/lib/module-doctest.html
With doctest, tests are EXACTLY where the code is. I've used doctest 
with incredibly successful results, in industry.



>> [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.
>
Reference counting by itself is not necessarily sufficient (because of 
circular references). That's why even Python, with its reference 
counting based system, has additional capabilities for finding circular 
references.

>> 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 believe that Alex's official job title at Google is "Uber Technical 
Lead". I'm sure I'll quickly be corrected if that's wrong, but trust me 
(and everyone else who's spent significant time reading c.l.p.) that 
Alex Martelli knows what he's talking about.

A lot of your arguments are the very typical arguments that people levy 
against Python, when they're first around it. And that's fine, most 
people go through that. They are taught programming in C++ or Java, and 
that that *that* is the way you're supposed to program. Then they see 
that Python does things in different ways, and automatically assume 
that Python is doing it wrong.

All I can say is that if you spend time with Python (and more 
importantly, read quality, well-established Python code that's already 
out there), you'll see and understand the Python way of doing things.


Jay P.