Python vs C for a mail server

[Jens Theisen]

Jay wrote:

> 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?

Not much frankly. Though I have no doubt that there is a lot of code that  
does, but more so in older C++ code.

> How does type safety tell you anything about the current usage of your
> program?

Quite a bit; of course, it's doesn't cover everything and clearly testing  
the semantics is still needed, but a lot of what code is used in what way  
is described by the type system. And I admit that I'm used to use the type  
system as documentation of what's going on.

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

Of course tests will cover a lot what static typing does and more. I'm  
just claiming that they can support each other.

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

A lot of people got me wrong on that, please see Paul's postings. I really  
didn't mean that literally.

> And is that fear based simply on "feeling", or on actual experience.

The former, that's why I did start this branch of the thread, though I'm  
already regretting it.

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

That really depends on who's code you're looking at, as in any language. I  
can believe there are more C++ obfuscaters out there than ones for Python.

I usually have little problems jumping into C++ code of other people but  
the principle reason for that will be that the people I'm working with  
have a very clean and expressive coding style.

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

That's indeed a good point for Python.

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

Whenever I encountered the need for circular references it was because an  
object, that was in some sense owned by another, needed a pointer back to  
it's owner. That solved easily with non-owning C-style pointers or weak  
pointers.

If you have an example where this is not sufficient, I'd be *very* keen on  
hearing it (it may be easy, I don't know).

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

You seem to be thinking that I was ironic. That was certainly not my  
intention. I was just trying to minimise the amount of flames I'll be  
getting.

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

I'm sorry to hear this, and whilst I'm certainly lacking experience in  
Python, I'm not one of those people.

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

I will.

Jens