Python vs C for a mail server

[Jim Segrave]

ya its supposed to be some stupid 6 month project which my friend has
to do.I am just helping him out.he may not be implementing a full
fledged rfc compliance mail server but may support some of the major
functionalities.so basically its an extra ordinary need.I just wanted
to know which language would be better for implementation and has
faster development cycle.I have heard a lot about python and its ease
of use.My point is it should be worth a 6 month project and speedy
development since he is already proficient in C/C++ socket programming
and taking the pain of learning python should be worth the effort.

In that case, you'll come closer to having a working mail server in
Python. I just hope that it's understood you won't have a mail server
which is ready to be used on the Internet for any but very limited
applications.

 

[Jim Segrave]

O'Reilly does have an Exim book, but it is out of date. It covers the
3.x family, while 4.x has been out for quite a while now. The 4.x
family is very different from 3.x, so the book isn't worth a whole
lot these days.

I'm on my second major mail system deployment built around Exim, and
would recommend it to anybody needing a robust, flexible mail server.

There is an exim 4 book out, but not via O'Reilly - I gather sales
were insufficient to persuade O'Reilly to do an update. As we use Exim
heavily, we have both the 3 and 4 books in our NOC, as well as sending
almost all new staff to Phil Hazel's excellent courses in Cambridge.

 

[Volker Grabsch]

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")()

No. The recommended way to do it is:

obj.foobar()

There is no systematic way to find this call.

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

In such a case I normally just grep for "foobar". I did so (and I'll do so)
in C/C++, Python, and any other language.


Any programming language allows you to do strange/stupid stuff. But none
of them encourages it. So I can't see your point in any way.



Greets,

Volker

 

[Donn Cave]

Quoth (e-mail address removed) (Alex Martelli):
....
|> 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")()
|>
|> ?
|
| "Encourages"? What a silly assertion. Python makes introspection
| easier than Java's Reflection, C#'s similar capabilities, and C/C++'s
| primitive dlopen/dlsym, but the existence of similar dynamic name
| resolution abilities in each of these languages reflects similar
| underlying real needs. The functionality is there for those cases in
| which it's needed, but it's silly to use it when not needed.

Silly indeed, and why would such a thing ever be needed? Yet it
does in fact occur in widely used Python software, in an application
where it of course wasn't really needed, rather was sort of convenient.
This is like the C enthusiast who tells you that any self-respecting
programmer won't mind accounting for storage, or the Perl enthusiast
who tells you that there's nothing about the language that encourages
hard-to-read code. Give people a feature like this, and they will
find a need for it, to the detriment of comprehensibility.

I'm not saying that we should therefore use C++ !, but let's be
realistic about the costs of Python's benefits.

Donn Cave, (e-mail address removed)

 

[Steven D'Aprano]

Any programming language allows you to do strange/stupid stuff. But none
of them encourages it.

One word: Intercal.

 

[Randall Parker]

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.

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.

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.

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.

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.

 

[Magnus Lycka]

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.

Ouch! Don't do that! As you've noticed, it's not very maintainable.

First of all, if you want to use Python well, embrace it's dynamic
nature, don't try to restrain it! It takes some time to let go of
the static thinking if one is used to it, but try. Just as lots of
programming guidelines (e.g. Parna's Principle and The Law of
Demeter) tells us that we should try to know and depend as little
as possible on the details in other pieces of code, the duck typing
behaviour in Python extends this one step further, to types.

Without proper tests, this might cause more problems than it solves,
but there is no excuse for not having proper automated tests for
software you develop in the 21st century!!!

You *don't* write an unmaintainable comment about what return
type to expect, you write unit tests that shows you how to use
each API that you implement. You run these tests often, fix them
as soon as they break, and you encourage their use as
documentation which describes through examples how to use you
APIs. (Sorry about the imperative tone. It's your life after
all, but don't blame Python for not fitting your style of
development.)

You should do that for statically typed languages as well. Knowing
that you got the correct type back gives you no assurance that
you got the right value!