Brought to you by Michael and Brian - take a Talk Python course or get Brian's pytest book

#321: A Memorial To Apps Past

Published Mon, Jan 30, 2023, recorded Mon, Jan 30, 2023
Watch this episode on YouTube
Play on YouTube
Watch the live stream replay

About the show

Sponsored by Microsoft for Startups Founders Hub.

Connect with the hosts

Join us on YouTube at pythonbytes.fm/stream/live to be part of the audience. Usually Tuesdays at 11am PT. Older video versions available there too.

Michael #1: git-sim

  • Visually simulate Git operations in your own repos with a single terminal command.
  • Generates an image (default) or video visualization depicting the Git command's behavior.
  • Features
    • Run a one-liner git-sim command in the terminal to generate a custom Git command visualization (.jpg) from your repo
    • Supported commands: log, status, add, restore, commit, stash, branch, tag, reset, revert, merge, rebase, cherry-pick
    • Generate an animated video (.mp4) instead of a static image using the --animate flag (note: significant performance slowdown, it is recommended to use --low-quality to speed up testing and remove when ready to generate presentation-quality video)
    • Choose between dark mode (default) and light mode
    • Animation only: Add custom branded intro/outro sequences if desired
    • Animation only: Speed up or slow down animation speed as desired
  • See images and animations on the github readme.

Brian #2: Why I Like Nox

  • Hynek Schlawack
  • I like tox and have wanted to try nox but couldn’t think of good reasons for a switch.
  • Hynek is a fan of both, so it’s nice to read his perspective.
  • The article starts with comparing doing the same thing in both
    • testing with Python 3.10 and 3.11 and adding the ability to pass in pytest arguments.
    • even with this example, I do admit that the nox example is easier to read, but a bit more verbose.
  • A second example of running a specific example combination of library and Python is quite a bit longer in nox, but there’s an interesting commentary: “… this is longer than the tox equivalent. But that’s because it’s more explicit and anyone with a passing understanding of Python can deduce what’s happening here – including myself, looking at it in a year. Explicit can be good, actually.”
  • Other benefits:
    • It’s a Python file with Python functions, you have the all of Python at your disposal when developing sessions to run.
    • It’s not “ini format”. Complex ini files get out of hand quickly.
    • nox has Python versions as fist class selectors.
  • Final note: “Again, this article is not a call to abandon tox and move all your projects to Nox – I haven’t done that myself and I don’t plan to. But if my issues resonate with you, there’s an option!”

Michael #3: I scanned every package on PyPi and found 57 live AWS keys

  • Scanning every release published to PyPi found 57 valid access keys.
  • Detecting AWS keys is actually fairly simple. A keypair consists of two components: the key ID and the key secret.
  • The key ID can be detected with the regular expression ((?:ASIA|AKIA|AROA|AIDA)([A-Z0-7]{16}))
  • The secret key can be detected with a much more general [a-zA-Z0-9+/]{40}.
  • Static PyPI data: github.com/orf/pypi-data

Brian #4: Getting Started With Property-Based Testing in Python With Hypothesis and pytest

  • Rodrigo Girão Serrão
  • Hypothesis and property based testing can be overwhelming at first.
  • So focused intro posts are quite helpful.
  • This post focuses on a couple of examples, gcd(), greatest common divisor, and my_sort(), a custom list sorter.
  • Good discussion of how property based testing is different and how to do it successfully, especially the order of development:
    • focus on developing properties of correct answers
    • develop a test that checks those properties
    • use hypothesis strategies to come up with input
    • pick @examples if necessary
    • narrow the range of input if necessary
      • caveat: I would have preferred hypothesis.assume() to limiting input in the first example. assume(not (n == m == 0))
      • see https://hypothesis.readthedocs.io/en/latest/details.html#hypothesis.assume
    • add more testing outside of hypothesis
      • In my experience it’s often easier for me to develop code with non-hypothesis test cases, then follow up with hypothesis. But after works also.
  • The mental gymnastics of thinking of properties for algorithmic code is worthwhile.

Extras

Michael:

Joke: Didn't come here to be called out


Want to go deeper? Check our projects