My Happy Python Workflow
This is my current python programming workflow. I’m quite happy with it. I constantly try to get better.
- I use Python3.x for all new projects.
- I use SublimeText3(ST3) for editing.
I use Two ST3 plugins –
- Anaconda catches things like unused variables, syntax errors, and PEP8 violations.
- I use PyYAPF formatting compulsively.
- ..and “Highlight Trailing Whitespace”, I find trailing whitespace unpleasant.
I take PEP8 warnings seriously and try to keep
- Vim in the shell. No plugins.
Start with a
README.mdin the project, even if it is a single file project.
I always use
virtualenv; Pipenv is a quick way to spin one up in the development environments.
Always capture the dependencies in
requirements.txt, unless I’m writing a setup.py
setup.pyfile is a great idea, and I should do it more often.
I always write a
For Python projects, the common “targets” are –
deps(for creating venvs and installing package dependencies),
package(for packaging into tarballs and wheels) and
testto run the test suite.
Makefileserves as contextual memory.
- For “scripting” applications, I like to avoid using third party libraries as much as possible and keep to the standard library.
I like providing a CLI interface to my scripts; I use
argparseoften, even if it is to provide basic
clicklooks neat, and I can see using it more often for larger projects.
docopthas fallen out of favour. Too fidgety for my taste.
python-poetryfor one project, and I like what it does.
I like putting package versions in my
setup.pyfiles. I don’t know if “Semantic versioning” is still a thing, but I like the x.y.z format, so I’m sticking to it.
- Any program that is big enough to have a setup.py file will also have CLI entry_points.
- I prefer writing small, self contained functions.
- I wouldn’t write a class unless I feel like I’m passing around too many variables between functions.
- I like putting unit testing in the same file as the code, if it’s a single file program.
- doc tests seemed like a good idea, but unit tests are a good way to grow the tests without redoing the doc tests.
- I have started writing type annotations, though nowhere near where I could be.
f-strings. I never seemed to remember the right way to call format strings before I got used to
I don’t like long variable names, especially ones with
snake_casefor me please.
- I use single character variable names when their meaning is clear from the context.
- I seldom read code without rewriting some parts of it. Many times the changes do become pull requests.
- I don’t like commented out code in middle of programs.
I’m still not good with the
- I prefer using multiprocessing over threads. I don’t remember the last time I wrote Python threading code.
I’m team single-quotes ’. I like when my string look like –
'hello, world!'instead of
- I haven’t used the walrus operator yet.
I always write “dunder main”(
__main__), unless its a throw away script (or a would’ve-been-a-bash-script script).
- You won’t catch me manipulating “path” to insert dependent library locations. I know how to use packages and virtualenvs.
- 4 spaces. No TABs characters in my programs. I do use the TAB key to tell the editor to indent appropriately.