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
and PyYapf
.
- 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
pyflakes
happy.
- Vim in the shell. No plugins.
- Start with a
README.md
in 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
- Writing a
setup.py
file is a great idea, and I should do it more often.
- I always write a
Makefile
.
- For Python projects, the common “targets” are –
deps
(for creating venvs and installing package dependencies), package
(for packaging into tarballs and wheels) and test
to run the test suite.
- The
Makefile
serves 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
argparse
often, even if it is to provide basic --help
.
click
looks neat, and I can see using it more often for larger projects.
docopt
has fallen out of favour. Too fidgety for my taste.
- I tried
python-poetry
for one project, and I like what it does.
- I like putting package versions in my
setup.py
files. 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.
- I love
f-strings
. I never seemed to remember the right way to call format strings before I got used to f-strings
, though .format
came earlier.
- I don’t like long variable names, especially ones with
camelCase
; snake_case
for 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
async
stuff.
- 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 "hello, world!"
.
- 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.