My Happy Python Workflow
Created:
May 06, 2020
by
Pradeep Gowda
.
Tagged:
python
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
andPyYapf
. - 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) andtest
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 tof-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.