How to use Python well?

[Jean-Michel Pichavant]

snorble wrote:
> I use Python a lot, but not well. I usually start by writing a small
> script, no classes or modules. Then I add more content to the loops,
> and repeat. It's a bit of a trial and error learning phase, making
> sure I'm using the third party modules correctly, and so on. I end up
> with a working script, but by the end it looks messy, unorganized, and
> feels hacked together. I feel like in order to reuse it or expand it
> in the future, I need to take what I learned and rewrite it from
> scratch.
>
> If I peeked over a Python expert's shoulder while they developed
> something new, how would their habits differ? Do they start with
> classes from the start?
>
> I guess I'm looking for something similar to "Large Scale C++ Software
> Design" for Python. Or even just a walkthrough of someone competent
> writing something from scratch. I'm not necessarily looking for a
> finished product that is well written. I'm more interested in, "I have
> an idea for a script/program, and here is how I get from point A to
> point B."
>
> Or maybe I'm looking for is best practices for how to organize the
> structure of a Python program. I love Python and I just want to be
> able to use it well.
>   
I guess this is happening to anyone using python for their everyday 
scripting. Writing tools to make life easier.
You start writing some quick and dirty code just to do the trick ASAP. 
Then after adding some features your realize it became a little more 
than a script but don't want to share it because the code is just a 
freaking mess that no one but you can understand.

Here are the things I do to avoid getting to that point:
1 - accept the fact that I will lose time trying to write it correcly 
from the begining
2 - the script has to be "importable" and usable by a 3rd python program.
3 - regulary test my code with the python shell importing the script
4 - use a linter (pylint) with all warnings activated.
5 - document the public class/function. This "force" me to expose the 
minimum interface, because like everyone, I dislike writing doc
6 - always include a argument parser.
7 - always use the logging module.
8 - if the project starts to become medium, write unitary tests.

And maybe the most important one, I always start from the upper level 
interface down to primitives (top-down programming ?). This helps me 
making suff really easy to use, with a clean interface. Sometimes the 
implementation can become tricky that way, I guess it's a matter of 
preference. In pratice, that just means that I write the method call 
before writing the method definition.

JM