Python Considered Harmful

[Gordon McMillan]

Eric Lee Green writes:

> Sorry, a bit of a troll involved in the title :-(. 

Becoming productive with Python means breaking some old 
habits - including the need to make flames.
 
> Anyhow, I have been prototyping a fairly large project in Python,
> and have come across some decided disadvantages as compared with
> more traditional language. Specificationally:
> 
> 1) The interface specification is the implementation. There is no
> seperate ".h" file such as with C++ that would contain the
> interface specification. With a big "C" or C++ project I print
> out the ".h" files and there's my interface specification
> (obviously I advocate and follow the practice of writing your C
> or C++ in an object-oriented modular manner!). I don't care about
> the implementation once the module has been debugged, all I care
> about is its interfaces. I can see the interfaces for the whole
> project by flipping through one slender folder with the .h files
> printed out. I can't do that with Python.

Or Java.

Think about what you're saying, though. You have the habit of 
letting the compiler point out the missing pieces. If you see 
that as a "language" issue, then you should be fair and admit 
that it's balanced by Python's syntactic simplicity. I see it as 
a "tool" issue, and the right tool for Python (as for any other 
language, but that's another story) is grep.

Practically, I often create "abstract" base classes which 
specify interface and have "pass" (or "assert 1 == 0") as 
method bodies. No, the compiler won't point out when you've 
let it get out of synch with the "concrete" subclasses, but it 
satisfies the need for a class overview.

More importantly, I regard the early stages of Python 
development as creating an executable design; so what I'm 
primarily working on is getting interfaces as simple as 
possible.
 
> 2) Debugging is a mess. The problem is that I tend to "stub"
> things a lot, or reference functions that have not yet been
> written (they're in the design doc, okay, so I know what their
> interfaces will be, I just haven't written them yet!). With a
> compiled language I run the compiler and linker and it tells me
> "hey stupid, you're missing something". With Python, I run it,
> and it tells me "doh, you forgot to create a method for
> 'checksum_packet'. I run it again, it tells me 'doh, you forgot
> to create a method for 'register_connection'. I run it again....
> ad nauseum. 

So? When you run a compile and get 42 syntax errors, how 
many actually need fixing? If you try to fix more than 5, you're 
probably breaking something. I usually fix the first, then do a 
quick scan to find obviously unrelated errors. In practice, that 
means rarely fixing more than 3 errors per compile cycle. OK, 
Python only finds them one at a time. Shrug.
 
> Of course, there's the one big advantage of Python -- it's
> quicker'n greased lightning for writing things in. I did in a
> month what would have taken four months in C++... just getting  a
> bit irritated in the process with the whole
> interface/implementation thing, because it's making keeping the
> design doc and the implementation in sync a pain in the @%!#....

Prototype for awhile. When you've got the interfaces clean, 
freeze it into a design doc. Over the period of 3 years, almost 
all my pre-Python beliefs about the "proper" way to develop 
systems have been completely shredded.

You might like to check out the interfaces alpha on the types-
SIG home page (along with the discussion Paul pointed you 
to). You should definitely check out DocTest in the System 
area of the contrib ftp site.


- Gordon