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.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
- 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.
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
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
.format came earlier.
- I don’t like long variable names, especially ones with
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
- 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.