Learning Python by Writing An Application (1)

I don’t read Slashdot as much as I used to, and so I have no idea if people still ask “What’s the best way to learn a new (programming) language”? The answer was and ever more shall be: read a decent introduction to it, then write an application with it. Not toy examples, but something you will use. Why? Because then you will have to get to grips with the file-handling and string-processing functions, as well as some basic UI functionality, as well as the specialist libraries you need for the task.

That’s what I’m doing for Python.

Assume you have a bunch of files in a high-level directory called MyFiles, on the drive of your working computer. You want to make a backup of this from time to time. If it’s small, the simplest thing to do is copy MyFiles onto an external drive. With a lot of files that could get time-consuming, so maybe a backup program will do. Except that backup programs often create their own special file structures, databases, or at the least, zip everything up. I don’t want to use a special program to manage the backup: I want to use Windows Explorer.

What I need is a clever copying program. I tell it the source directory and the backup directory, and it recursively scans down the source tree, copying only the newfiles and the new directories it finds. Then, if I’ve asked it to, it removes any files from the backup directory that I deleted in the source directory since the last backup.

That’s the sort of thing that Python is good for. So I downloaded JetBrains’ PyCharm Community edition (because free) and started. I know how to program, and I understand basic Python syntax, but what I don’t have is a lot of familiarity with all the libraries, and especially Tkinter, which is what I needed for the user interface.

How does one cut code without knowing all the libraries? Slowly, with various reference websites open in the browser. That’s what manuals are for.

This illustrates the difference between being a programmer, and being a productive (insert name of language here) programmer. Because I’m a programmer, I can break a task into activities the computer or user needs to do (‘get the spare space on the destination drive’), and it usually turns out that the tasks I identify correspond pretty closely with the functions available in the system libraries. Programmers tend to think alike.

I understand control flow, arrays, variable types and declaration, threading, and use of functions to make code readable and maintainable. (I know, you want to hire me already.) I learned that writing FORTRAN, C, and VBA. Writing long chains of macros and the queries for them in Access is programming of a kind as well, as is constructing chains of raw SQL. It’s all about organising the resources of the language to get done what you need to get done.

Faced with a new language, I look for how those things are done, as well as any other cool tricks or idiosyncrasies it has. And, because I’m a programmer, I Read A Freaking Manual first. (This approach will not work with LISP and other such languages. Those really do need to be learned from zero, or you will miss the point.) On a meta-level, I’m Dreyfus-Proficient. That’s the engineering training. I’m just not slick.

All that said, I wouldn’t go for a Python job because one of the requirements is muscle-memory of the main system libraries, and familiarity with whatever the job-specific libraries are. I don’t want to be one of those guys who bluffed about their skills.

I have the sneaking suspicion that I’ve written VBA in Python, and that a Truly Pythonic Programmer would do the whole thing in two lines of code, one of which is a recursively self-referential array of filenames, and the other of which would implement a beautiful wxPython interface in less than twenty characters.

‘Pythonic Programming’ is a Thing. It’s a style. TPPs can do in a line what RJPs need six hundred lines to do. But becoming a TPP takes serious study, not to mention the right examples.

Next post, I’ll talk about the program.