Getting happier ;-), but wondering if I'm thinking pythonically

[Delaney, Timothy C (Timothy)]

Line 29 is:

    except:         # This seems to be deprecated - why?

The reason for not using a bare except is that it is likely to catch stuff you are not prepared to deal with - for example, MemoryError and KeyboardException.

Only catch the things you can deal with at the time.

> From: Brian Quinlan [mailto:brian at sweetapp.com]
>
> 2. explicitly closing files is not usually necessary (e.g. line 35)

In CPython. Except that if you don't explicitly close files that you are *writing* then you may find that data isn't flushed.

Get used to explicitly closing files - and do it in a finally: block!

> 3. bare return statements are not necessary (e.g. 38)

But there's no harm, and can be useful as documentation - especially if you have multiple exit points in a function - it can be very useful to have the consistency of *every* exit point being a 'return'.

> 4. the decision to exit an application should be made close to the
>    top level (this is true of other languages with exception handling)
>    (e.g. line 52)

Not necessarily. If there is a fatal condition, choosing to exit at that point is fine. However, normally you should just let the exception propagate so that there is some context (perhaps have a catch-all case at the very top level to log any uncaught exceptions, then exit).

> 5. you should generate more descriptive error messages (e.g. line 30)

This is related to my comments for point 4. A stack trace is much more descriptive ;)

> 6. utility functions (e.g. find_len) are normally placed near 
> the top of the module

I usually move them out to a separate module ;)

> 7. "str" is a bad name for an identifier since it masks a built-in 
>    (e.g. line 164)

Definitely. Get to know the builtin names and avoid shadowing them. It's useful to use a syntax-colouring editor which colours the built-in names.

Tim Delaney