This is my current python programming workflow. I’m quite happy with it. I constantly try to get better.

  1. I use Python3.x for all new projects.
  2. I use SublimeText3(ST3) for editing.
  3. I use Two ST3 plugins – Anaconda and PyYapf.
  4. Anaconda catches things like unused variables, syntax errors, and PEP8 violations.
  5. I use PyYAPF formatting compulsively.
  6. ..and “Highlight Trailing Whitespace”, I find trailing whitespace unpleasant.
  7. I take PEP8 warnings seriously and try to keep pyflakes happy.
  8. Vim in the shell. No plugins.
  9. Start with a README.md in the project, even if it is a single file project.
  10. I always use virtualenv; Pipenv is a quick way to spin one up in the development environments.
  11. Always capture the dependencies in requirements.txt, unless I’m writing a setup.py
  12. Writing a setup.py file is a great idea, and I should do it more often.
  13. I always write a Makefile.
  14. 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.
  15. The Makefile serves as contextual memory.
  16. For “scripting” applications, I like to avoid using third party libraries as much as possible and keep to the standard library.
  17. I like providing a CLI interface to my scripts; I use argparse often, even if it is to provide basic --help.
  18. click looks neat, and I can see using it more often for larger projects.
  19. docopt has fallen out of favour. Too fidgety for my taste.
  20. I tried python-poetry for one project, and I like what it does.
  21. 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.
  22. Any program that is big enough to have a setup.py file will also have CLI entry_points.
  23. I prefer writing small, self contained functions.
  24. I wouldn’t write a class unless I feel like I’m passing around too many variables between functions.
  25. I like putting unit testing in the same file as the code, if it’s a single file program.
  26. doc tests seemed like a good idea, but unit tests are a good way to grow the tests without redoing the doc tests.
  27. I have started writing type annotations, though nowhere near where I could be.
  28. 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.
  29. I don’t like long variable names, especially ones with camelCase; snake_case for me please.
  30. I use single character variable names when their meaning is clear from the context.
  31. I seldom read code without rewriting some parts of it. Many times the changes do become pull requests.
  32. I don’t like commented out code in middle of programs.
  33. I’m still not good with the async stuff.
  34. I prefer using multiprocessing over threads. I don’t remember the last time I wrote Python threading code.
  35. I’m team single-quotes ‘. I like when my string look like – 'hello, world!' instead of "hello, world!".
  36. I haven’t used the walrus operator yet.
  37. I always write “dunder main”(__main__), unless its a throw away script (or a would’ve-been-a-bash-script script).
  38. You won’t catch me manipulating “path” to insert dependent library locations. I know how to use packages and virtualenvs.
  39. 4 spaces. No TABs characters in my programs. I do use the TAB key to tell the editor to indent appropriately.