A modest indentation proposal

[brueckd at tbye.com]

On 1 Dec 2001, Kragen Sitaker wrote:

> I'm interested to hear what you find to be common causes of problems
> when you're programming in Python.

Here's some long-winded ones off the top of my head:
- I've yet to find a really good way to organize modules and functions
I've written and know I'll want to use again later. If there's something
annonying or missing in Python then usually a small function or module
will fix that, but then I end up littering my home and work computers with
various copies of different versions of that same thing, where some are
accessed by being in the same directory as whatever program I'm working
on, others by making sure the Python path includes some dump-all
directory, and others by modifying the Python path at runtime. Maybe the
solution is sort of a private CPAN-like thing, but I've never gotten
around to working on it.

- A lot of times I find my self over-engineering a solution, a problem
made worse by the fact that so many projects have shifting/evolving
requirements. I used to believe that it was best to get it right the first
time, but often "right" can't even be defined until after the first
release, and then it changes with each subsequent release. Assuming you've
invested sufficiently in your testing, a complete rewrite can be cheaper
(in both time and effort) than the cost of getting it "right" first and
then pushing the original version to adapt to changing requirements. To
help me overcome my aversion to rip-it-out-and-toss-it we actually
scheduled a complete rewrite of a product after each major release. We're
just starting the third rewrite, all our tests pass, and we have
essentially zero code baggage (hacks added over time to make the product
do what we didn't anticipate was needed) and loads of new features, all in
the same amount of time we had scheduled originally just to add the new
features. It still seems crazy to me but it has also gone so much easier
than some past projects. I'm still trying to really understand why it has
worked so well, but we're really benefitting from it anyway.

- Too often I fail to use neat Python idioms, instead relying on using C,
C++, Java, etc. techniques in Python. I'm anxious to read anyone's books
on Python "patterns" or programming "gems" as they represent potentially
untapped power.

- Because Python code is so concise I often let little functions grow to
50 or more lines. Sometimes that's ok, but in Python that's often too much
punch for a single function (you can do a heck of a lot in 50 lines!) and
then that function ends up being too difficult to thoroughly test.

- I sometimes abuse dynamic types by letting function parameters take on
too large a set of meanings. One IMO beautiful example of where this works
well and is ok is in asynchat, where you tell the module to read data from
a socket until some terminator is reached. If the terminator is None, it
reads all data, if the terminator is a number, it means read that many
bytes, and if it's a string, it means read until that token is found in
the data. Unfortunately, in my own code there's rarely that level of
cohesion among the different meanings of a parameter.

In all the problems I've encountered so far, I can't think of any that
would be appropriately solved by modifying the language - it's all about
learning how to better use the tools in front of me and replacing bad
habits with better ones.

-Dave