Python vs C for a mail server

[Jay Parlar]

Randall Parker wrote:
> Alex Martelli wrote:
>
>> 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 about the role and
>> meaning of frep, or zappolop's result.  The code's author must 
>> obviously
>> add a little comment here to clarify -- and in that little comment,
>> adding the information about type, if at all relevant, is an obvious
>> task.
>
> Yes, one can use such simple types that the types do not tell you that
> much. They do tell you something though. The arg and return types are
> not list structures for example. They aren't floats either.
>
> However, C/C++ at least provide a way to make types tell you far more.
> For example, one could declare enum types:
>
> typedef enum MyArgType
> {
>    // a bunch of enum const names here
> } MyArgType;
> typedef enum MyResultType
>    // another bunch of enum const names
> } MyResultType;
>
> Then your example above becomes
>
> MyResultType zappolop(MyArgType frep) { ...
>
>  and that's a lot more insightful.
>
Except once a type starts to get a little bit complicated, you're not 
going to be able to "keep it in your head", and you'll have to go back 
to the C++ definition of the type anyway when you want to know what it 
does. Much like you'd have to go back to the Python source of a class. 
(This is of course assuming that you put a comment in your Python code 
saying that a certain kind of class is expected. I find it's obvious 
about 80% of the time what's expected).


> I return objects in Python and in C++. In C++ I can see what their
> types are right on the m method signature. In Python I've got to write
> a comment on the line above it. If I change what type I return and
> forget to change the comment then the code isn't correctly documented
> anymore. I've done recently and found out with a runtime error while
> testing the Python. In C++ if I'd changed the return type the compiler
> would have told me if I didn't use it that way somewhere else.

Yeah, but you can't *just* change the type you're returning, and expect 
to be done. You'll also have to change the source code of the function 
to actually return something of that type. And you'll have to change 
all the places where the function is called, to make sure that the 
caller is storing the result in an appropriately typed variable.

Often times in Python, the thing you're returning is useful because of 
duck-typing, not because it's actually of a particular class. Maybe in 
some piece of code, you're returning a file() object, and all the 
callers really care about is the ability to do a read() and write() on 
that object.

Maybe later in the lifecycle of your program, you no longer store 
things in the filesystem directly, but in a database. You'd have to 
change your function such that it no longer returns a file() object, 
but some object that instead is connecting to a database. But you still 
only need to call read() and write() on it.

Well guess what: The *only* code you'll have to change is inside the 
function returning the object, none of the callers would have to 
change. That's completely different from C++, where you'll have to 
change not only the return type and the function, but you'll also have 
to change every single calling function to be aware of this new db 
object. And not just how the callers store the returned object, but 
also how they use that object. That's a LOT of work, for really no 
gain.

And that's the ENTIRE point (as I see it) of the Python typing system. 
Usually you know what you want to do, and you shouldn't have to fight 
to do it.

If you haven't heard the term "duck typing" before, Wikipedia has a 
decent page on it, and a simple Google search will return many more 
results.

> There are a lot of stages at which to reduce the chance of bugs. While
> coding an editor can give you more help with code completion if you
> have more static typing. At compile time the compiler can tell you
> about errors if it knows the types you are using.
>

Yeah, but it can only tell you about type errors, and those aren't 
really critical. They're the kind of error that takes a second to fix 
when found. Yet *how much* time is often spent fighting with a compiler 
to make it accept the types you actually want to use?

> I use PyChecker and PyLint and while they are incredibly helpful (and
> I'm grateful to their authors just as I am to Python's developers) they
> do not tell me as much as Borland's C++ compiler does. I get more
> runtime errors with my Python code than with my C++ code.
>

That's to be expected, but the time needed to get to a runtime error is 
so much less in Python (especially if you've got good unit/integration 
tests). I recommend you bring IPython into your development tools, so 
you can easily import small parts of your code and hand test them in 
isolation.

> Still, I find Python useful and better than C++ in some situations.
> But I wish it provided better options for allowing me to indicate types
> so that more errors could get caught sooner and so that editor code
> completion could be smarter.

Are you really getting a lot of type errors, so many that it's 
disrupting your development cycle? Just on my own experience, I get 
more type errors in C++ (ie. the compiler getting angry at me) because 
it's so picky about everything, and I have to spend so much time 
working around C++'s typing system. I don't really get a lot of type 
errors in my Python code, especially working with libraries I've used a 
lot.


And if you *still* feel weary, then you can do some kind of adaption 
(see Alex Martelli's PEP 246 http://www.python.org/peps/pep-0246.html). 
There are two adaption packages out there, one from Zope (which is also 
used by Twisted), and one by PJE, called PyProtocols, 
http://peak.telecommunity.com/PyProtocols.html

I have used PyProtocols extensively in the past, with great success. 
Adaption seems to work best in the areas of frameworks, where a large 
chunk of code written by someone else is expecting *you* to pass it 
objects of the right (duck) type.

Jay P.