Python Bytes: #321 A Memorial To Apps Past

<a href='https://www.youtube.com/watch?v=gxNBvPn0JpE' style='font-weight: bold;'>Watch on YouTube</a><br> <br> <p><strong>About the show</strong></p> <p>Sponsored by <a href="http://pythonbytes.fm/foundershub2022"><strong>Microsoft for Startups Founders Hub</strong></a>.</p> <p><strong>Connect with the hosts</strong></p> <ul> <li>Michael: <a href="https://fosstodon.org/@mkennedy"><strong>@mkennedy@fosstodon.org</strong></a></li> <li>Brian: <a href="https://fosstodon.org/@brianokken"><strong>@brianokken@fosstodon.org</strong></a></li> <li>Show: <a href="https://fosstodon.org/@pythonbytes"><strong>@pythonbytes@fosstodon.org</strong></a></li> </ul> <p>Join us on YouTube at <a href="https://pythonbytes.fm/stream/live"><strong>pythonbytes.fm/stream/live</strong></a> to be part of the audience. Usually Tuesdays at 11am PT. Older video versions available there too.</p> <p><strong>Michael #1:</strong> <a href="https://github.com/initialcommit-com/git-sim"><strong>git-sim</strong></a></p> <ul> <li>Visually simulate Git operations in your own repos with a single terminal command.</li> <li>Generates an image (default) or video visualization depicting the Git command's behavior.</li> <li>Features <ul> <li>Run a one-liner git-sim command in the terminal to generate a custom Git command visualization (.jpg) from your repo</li> <li>Supported commands: <code>log</code>, <code>status</code>, <code>add</code>, <code>restore</code>, <code>commit</code>, <code>stash</code>, <code>branch</code>, <code>tag</code>, <code>reset</code>, <code>revert</code>, <code>merge</code>, <code>rebase</code>, <code>cherry-pick</code></li> <li>Generate an animated video (.mp4) instead of a static image using the <code>--animate</code> flag (note: significant performance slowdown, it is recommended to use <code>--low-quality</code> to speed up testing and remove when ready to generate presentation-quality video)</li> <li>Choose between dark mode (default) and light mode</li> <li>Animation only: Add custom branded intro/outro sequences if desired</li> <li>Animation only: Speed up or slow down animation speed as desired</li> </ul></li> <li>See images and animations on the github readme.</li> </ul> <p><strong>Brian #2:</strong> <a href="https://hynek.me/articles/why-i-like-nox/"><strong>Why I Like Nox</strong></a> </p> <ul> <li>Hynek Schlawack</li> <li>I like <code>tox</code> and have wanted to try <code>nox</code> but couldn’t think of good reasons for a switch. </li> <li>Hynek is a fan of both, so it’s nice to read his perspective.</li> <li>The article starts with comparing doing the same thing in both <ul> <li>testing with Python 3.10 and 3.11 and adding the ability to pass in <code>pytest</code> arguments.</li> <li>even with this example, I do admit that the <code>nox</code> example is easier to read, but a bit more verbose.</li> </ul></li> <li>A second example of running a specific example combination of library and Python is quite a bit longer in <code>nox</code>, but there’s an interesting commentary: “… this is longer than the <em>tox</em> equivalent. But that’s because it’s more <em>explicit</em> 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.”</li> <li>Other benefits: <ul> <li>It’s a Python file with Python functions, you have the all of Python at your disposal when developing sessions to run.</li> <li>It’s not “ini format”. Complex ini files get out of hand quickly.</li> <li><code>nox</code> has Python versions as fist class selectors.</li> </ul></li> <li>Final note: “Again, this article is <strong><em>not</em></strong> a call to abandon <em>tox</em> 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!”</li> </ul> <p><strong>Michael #3:</strong> <a href="https://tomforb.es/i-scanned-every-package-on-pypi-and-found-57-live-aws-keys/">I scanned every package on PyPi and found 57 live AWS keys</a></p> <ul> <li>Scanning every release published to PyPi found 57 valid access keys.</li> <li>Detecting AWS keys is actually fairly simple. A keypair consists of two components: the <code>key ID</code> and the <code>key secret</code>. </li> <li>The <code>key ID</code> can be detected with the regular expression <code>((?:ASIA|AKIA|AROA|AIDA)([A-Z0-7]{16}))</code></li> <li>The secret key can be detected with a much more general <code>[a-zA-Z0-9+/]{40}</code>. </li> <li>Static PyPI data: <a href="https://github.com/orf/pypi-data">github.com/orf/pypi-data</a></li> </ul> <p><strong>Brian #4:</strong> <a href="https://semaphoreci.com/blog/property-based-testing-python-hypothesis-pytest">Getting Started With Property-Based Testing in Python With Hypothesis and</a> <a href="https://semaphoreci.com/blog/property-based-testing-python-hypothesis-pytest">p</a><a href="https://semaphoreci.com/blog/property-based-testing-python-hypothesis-pytest">ytest</a> <a href="https://semaphoreci.com/blog/property-based-testing-python-hypothesis-pytest"></a></p> <ul> <li>Rodrigo Girão Serrão</li> <li>Hypothesis and property based testing can be overwhelming at first.</li> <li>So focused intro posts are quite helpful.</li> <li>This post focuses on a couple of examples, <code>gcd()</code>, greatest common divisor, and <code>my_sort()</code>, a custom list sorter.</li> <li>Good discussion of how property based testing is different and how to do it successfully, especially the order of development: <ul> <li>focus on developing properties of correct answers</li> <li>develop a test that checks those properties</li> <li>use hypothesis strategies to come up with input</li> <li>pick <code>@examples</code> if necessary</li> <li>narrow the range of input if necessary <ul> <li>caveat: I would have preferred <code>hypothesis.assume()</code> to limiting input in the first example. <code>assume(not (n == m == 0))</code></li> <li>see https://hypothesis.readthedocs.io/en/latest/details.html#hypothesis.assume</li> </ul></li> <li>add more testing outside of hypothesis <ul> <li>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.</li> </ul></li> </ul></li> <li>The mental gymnastics of thinking of properties for algorithmic code is worthwhile.</li> </ul> <p><strong>Extras</strong> </p> <p>Michael:</p> <ul> <li>First stream from the sweet new mac mini.</li> <li><a href="https://tapbots.com/ivory/">Ivory released</a> for Mastodon, but <a href="https://fosstodon.org/@maffeis@mastodon.social/109745470604839977">others too</a>.</li> <li>Nice memorial <a href="https://tapbots.com/tweetbot/">https://tapbots.com/tweetbot/</a></li> <li>We’ll be doing a live in-person event at PyCon, <a href="https://pythonbytes.fm/friends-of-the-show">become a friend of the show</a> to get notified.</li> </ul> <p><strong>Joke:</strong> <a href="https://fosstodon.org/@rmi@cloudisland.nz/109644187442825281">Didn't come here to be called out</a></p>