Development tools and practices for Pythonistas

[CM]

On Apr 26, 10:39 am, snorble <snor... at hotmail.com> wrote:
> I'm not a Pythonista, but I aspire to be.
>
> My current tools:
>
> Python, gvim, OS file system
>
> My current practices:
>
> When I write a Python app, I have several unorganized scripts in a
> directory (usually with several named test1.py, test2.py, etc., from
> random ideas I have tested), and maybe a todo.txt file.

First, give your files meaningful names.  test1.py, test2.py...no
wonder you have to spend an hour just figuring out where you left
off.  Imagine instead if these were modules called
DiskAccessUtilities.py and UserPreferencesPanel.py.  You should also
use highly descriptive names in naming classes and functions, too,
with functions being verbs and don't be afraid of long(ish) function
names like AddNewCustomerToDatabase()

> Then I hack away, adding features in a semi-random order.

I'd spend an hour with your TODO list and break it into priority
categories, like High, Med, Low, and It Would Be Nice, and then take
them strictly in that order.  I'd also date the issues so you have a
sense for how long something has been waiting to be fixed.

> Then I get busy with other things. Maybe one week I spend 20 hours > on development. The next week, no time on development. A few
> weeks later when I have some time, I'm excited to get back to making
> progress, only to find that I have to spend 30-60 minutes figuring out
> where I left off.

I would try to not stop in the middle of creating a new feature or
fixing a bug, but try to finish it out before taking a week off.  This
way, when you come back, you can just tackle something from the High
Priority stack and not have to figure out where you were.

> The code is usually out of sync with todo.txt.

That's just a matter of being disciplined.  When I fix a bug, I simply
cut the bug from the TODO part to the DONE part of the .txt file,
nearly every time.  It requires no effort compared to actually fixing
the bug, yet it feels satisfying to get that text moved.

> would help me to make more consistent progress, and spend less time
> bringing myself up to speed after some time off.

Are you documenting your code?  That can help (I need to get better
about that as well).  Also, are things broken down into modules that
are self-contained?  That also can help much.  Is the TODO.txt always
open while you are working?  It should be.  Lastly, keeping some kind
of notebook or even Post-Its or a bulletin board over your desk with
notes as to what's next and where to hunt in your code to get at it
should help.  Imagine if you take two weeks off, come back, want to
work on the project, and you find this note on your bulletin board:
"In the CustomersPanel.py module, add support for a wxSearchCtrl
(search bar) that searches the Former_Customers table in the main
database..."  Now you are ready to jump right in!

> I really like the idea of having a list of features, and tackling
> those features one at a time. I read about people who do this, and
> each new features gets a new minor version number.

Is that true?  I'm under the impression that projects do a bunch of
changes (bug fixes, and new features) and then release a new version
that has a decent amount of changes.  I don't think people want tons
of versions of most projects around, but that each release should have
an appreciable amount of good changes.

> to concepts. Like, "each feature gets its own directory".

I guess it depends on your project, but that sounds needlessly complex
and way too tough with a VCS.  I'd say just don't go there.

Once you use a VCS you will probably settle into a better pattern, but
things like good naming, documenting, notes, prioritizing features/
bugs, and roadmaps don't magically go away.  Software development
takes long range thinking and some organizational discipline.

Che