Python Bytes: #221 Pattern matching and accepting change in Python with Brett Cannon

<p>Sponsored by Datadog: <a href="http://pythonbytes.fm/datadog"><strong>pythonbytes.fm/datadog</strong></a></p> <p>Special guest: <a href="https://twitter.com/brettsky"><strong>Brett Cannon</strong></a></p> <p><strong>Brian #1:</strong> <strong>Keeping up with Rich</strong></p> <ul> <li>Will McGugan has been building <a href="https://github.com/willmcgugan/rich">Rich</a></li> <li>It looks like it’s on its way to becoming a full fledged TUI (text user interface)</li> <li>December: <a href="https://rich.readthedocs.io/en/latest/live.html">Live view</a>: no blog post on that, I don’t think.</li> <li>January: <a href="https://rich.readthedocs.io/en/latest/tree.html">Tree view</a>: <a href="https://www.willmcgugan.com/blog/tech/post/rich-tree/">Rendering a tree view in the terminal with Python and Rich</a></li> <li>February: <a href="https://rich.readthedocs.io/en/latest/layout.html">Layouts</a>: <a href="https://www.willmcgugan.com/blog/tech/post/building-rich-terminal-dashboards/">Building Rich terminal dashboards</a> <ul> <li>fun <a href="https://github.com/willmcgugan/rich/blob/master/examples/fullscreen.py">fullscreen.py</a> example, uses Live view</li> </ul></li> <li>Also, <code>python -m rich</code> will display a demo screen that shows tons of the stuff that Rich can do</li> <li>Many of the features also have a stand alone demo built in, like:</li> </ul> <pre><code> $ python -m rich.layout $ python -m rich.tree $ python -m rich.live </code></pre> <ul> <li>Although I haven’t figured out how to kill the live demo. it doesn’t seem to time out, and it eats Ctrl-C in my terminal.</li> <li>I’d really like to use Rich for interactive stuff, like keyboard interrupts and arrow keys and tab and such. It’d be fun.</li> <li>Which brings me to the bottom right corner of the <code>python -m rich</code> output. It includes a <a href="https://github.com/sponsors/willmcgugan">GitHub Sponsor link for Will</a>. </li> <li>Also, Will, unless it’s a contradiction to RTD TOS, I think you should include a Sponsor link in the <a href="https://rich.readthedocs.io/en/latest/">Rich documentation</a>. </li> <li>Let’s convince Will to make Rich a full TUI.</li> </ul> <p><strong>Michael #2:</strong> <a href="https://suade.org/dev/12-requests-per-second-with-python/"><strong>12 requests per second</strong></a></p> <ul> <li>If you take a look around the blogosphere at various benchmarks for Python web frameworks, you might start to feel pretty bad about your own setup.</li> <li>The incredible work of the guys at <a href="https://magic.io/blog/uvloop-blazing-fast-python-networking/">magic stack</a>, getting <strong>100,000 requests per second</strong> from <a href="https://github.com/MagicStack/uvloop">uvloop</a> in a single thread.</li> <li>There’s the FastAPI benchmarks</li> <li>Even more mind-blowing is <a href="https://github.com/squeaky-pl/japronto">Japronto</a> which claims an insane <strong>1.2 million requests per-second</strong> in a single thread</li> <li>But what about your “boring” Flask or Django app? And how realistic are these benchmarks? Usually, not very.</li> <li>Here’s an article diving into this for a “proper” ORM style app.</li> <li>12 - 80 requests per sec: Both our sync workers are now hitting a blazing <strong>12</strong> <strong>requests per second</strong> 😅 Using async workers seems to help a lot, but oddly Sanic struggles here.</li> <li>Be sure to run in prod on a “real” server setup (nginx + gunicorn or whatever)</li> <li>Compare this to Talk Python Training - Python 3, uWSGI, Pyramid, MongoDB, $20/mo server</li> <li>Get around 125 requests/sec @ 100ms response time on a single server.</li> <li>More realistically, we can handle about 10,000-20,000 concurrent “realistic” users before performance suffers.</li> </ul> <p><strong>Brett #3:</strong> <a href="https://crates.io/crates/python-launcher"><strong>Python Launcher for Unix</strong></a> <strong>reaches RC (probably 😉)</strong></p> <ul> <li>Exclusive! 😁</li> <li>Started right after PyCon US 2018</li> <li>Implemented in Rust (it’s my “good size” Rust learning project)</li> <li>The Python Launcher for Windows works by: <ul> <li>Checking the shebang line</li> <li>If <code>VIRTUAL_ENV</code> is set</li> <li>Find the newest <code>pythonX.Y</code> version/command on <code>$PATH</code></li> <li>Can specify specific versions via e.g. <code>-3</code> or <code>-3.9</code></li> <li><code>PY_PYTHON</code> and <code>PY_PYTHON3</code> environment variables supported</li> <li><code>--list</code> also works</li> <li>Can use <code>PYLAUNCH_DEBUG</code> to see what the tool is doing</li> <li><code>--help</code> covers all of this</li> </ul></li> <li>Unix version differs in the preference of shebang versus <code>VIRTUAL_ENV</code> over shebang <ul> <li>Figure on Unix you will <code>chmod</code> the executable bit if you truly care about the shebang</li> <li>I also assume at this point people will use entry points if they really want to tie something to an interpreter version</li> <li>How often do people peg their scripts to a specific Python version instead of <code>python2</code> or <code>python3</code>?</li> <li>What do people think of this logic swap (hence the “probably”)?</li> </ul></li> <li>Unix bonus feature: will automatically use any virtual environment found in <code>.venv</code> in the working directory (and no, what directory is considered is not configurable 😁)</li> <li>All of this has made it <code>py</code> my preferred way of running Python on my machine</li> <li>Really useful with <a href="https://starship.rs/">Starship</a> and its <a href="https://starship.rs/config/#python">Python support</a> (does away with the big “Tip” box they have for the <code>python_binary</code> setting)</li> </ul> <p><strong>Michael #4:</strong> <a href="https://wasimlorgat.com/editor"><strong>Build a text editor with Python and curses</strong></a></p> <ul> <li><code>[curses](https://ift.tt/37J1B7h> is a library to avoid having to deal with low level issues like efficiently painting to the terminal screen and receiving user input.</li> <li>a barebones <code>curses</code> application</li> </ul> <pre><code> import curses def main(stdscr): while True: k = stdscr.getkey() if k == "q": sys.exit(0) if __name__ == "__main__": curses.wrapper(main) </code></pre> <ul> <li>Clear the screen with <code>stdscr.erase()</code></li> <li>Adding text (a line of text) to the screen: <code>stdscr.addstr(row, 0, line)</code></li> <li>The article covers interesting topics like a “view” into the file that fits the screen and a cursor you move around with arrow keys</li> </ul> <p><strong>Brett #5:</strong> <a href="https://mail.python.org/archives/list/python-committers@python.org/message/SQC2FTLFV5A7DV7RCEAR2I2IKJKGK7W3/"><strong>Pattern matching</strong></a> <strong>and accepting change in Python</strong></p> <ul> <li>The “5-barrel foot-gun” in the room (to use Brian’s words from the last episode 😉)</li> <li>Usual places have people commenting from “I like this” to screaming bloody murder</li> <li>I think there are many “new” people to the language who don’t know Python prior to Python 3, so they don’t realize how much things used to regularly change in the language</li> <li>Pattern matching was <strong>very</strong> much debated publicly, so this wasn’t a secret (and I’m sorry if you didn’t have the time to participate, but Python development doesn’t even always wait for me and I’m on the SC, so …) <ul> <li>The 2020 SC also announced publicly the possibility of this back in December with their recommendation to accept the PEP(s)</li> </ul></li> <li>Also usual comments of “why did they waste their time on <em>that</em>?!? Go fix packaging!” (and it’s almost always packaging 🙄) <ul> <li>This is open source: some people wanted to put their personal time and effort into trying to get pattern matching into Python, so that’s what they did</li> <li>If you want to help with Python’s packaging ecosystem, you can do so but trying to tell people what they “need” or “should” do with their time is simply rude</li> </ul></li> <li>History repeats itself: every change is unwelcome unless it solves <em>your</em> problem <ul> <li>Pattern matching very much opens up opportunities for certain problems that were not easily possible before, e.g. parsers and compilers are classics (and hence why they are so often implemented in functional languages)</li> <li>I don’t think you will see this in nearly every code base like you do e.g. list comprehensions</li> <li>E.g. I’m sure data scientists aren’t saying any of this since they got <code>@</code>, right? 😉</li> </ul></li> <li>People also claiming it isn’t Pythonic need to note that Guido helped drive this <ul> <li>Do <em>you</em> know what is Pythonic better than Guido? 😉</li> <li>He might not be BDFL anymore, but that doesn’t mean he still doesn’t have good design sense, i.e. if you like Python up to this point then trust Guido’s gut that this is a good thing</li> <li>“In Guido We Trust” (you can even <a href="https://nerdlettering.com/collections/mugs-for-python-developers/products/in-guido-we-trust-python-mug-black">get it on a mug</a> 😉)</li> </ul></li> <li><strong>If</strong> you use pattern matching in <strong>real-world code</strong> and have feedback to provide with enough time to consider it <strong>before b1</strong>, then please let python-dev know <ul> <li>E.g. there is a chance to change the meaning of <code>_</code> if that is truly your biggest hang-up</li> </ul></li> <li>This will all probably become a blog post <ul> <li>Running title is “The Social Contract of Open Source”</li> <li>These kinds of attitudes against people trying their best to make things better for folks is what led to Guido retiring from being the BDFL in the first place, me having to take a month off from open source every year, etc.</li> </ul></li> <li>Aside: more influenced by Scala than by Haskell (not sure where Michael and some other people I’ve seen online got the idea Haskell played into this) <ul> <li>Did you know we got list comprehensions from Haskell?</li> </ul></li> </ul> <p><strong>Brian #6:</strong> <a href="https://www.python.org/dev/peps/pep-0636/#appendix-a-quick-intro"><strong>A Quick Intro to Structural Pattern Matching in Python</strong></a></p> <ul> <li>aka the “switch” statement. I mean, the “match” statement.</li> <li>Also known as PEP 636, <a href="https://www.python.org/dev/peps/pep-0636/#appendix-a-quick-intro">Appendix A — Quick Intro</a> <ul> <li><a href="https://github.com/gvanrossum/patma/blob/master/README.md">courtesy Guido van Rossum</a></li> </ul></li> <li>This finally helps me to get my head around simple uses of the new syntax for 3.10</li> <li>simple form:</li> </ul> <pre><code> def http_error(status): match status: case 400: return "Bad request" case 401: return "Unauthorized" case 403: return "Forbidden" case 404: return "Not found" case 418: return "I'm a teapot" case _: # _ acts as a wildcard and never fails to match return "Something else" </code></pre> <ul> <li>you can combine several matches using <code>|</code></li> </ul> <pre><code> case 401|403|404: return "Not allowed" </code></pre> <ul> <li>Patterns can look like unpacking assignments, and can be used to bind variables:</li> </ul> <pre><code> # The subject is an (x, y) tuple match point: case (0, 0): print("Origin") case (0, y): print(f"Y={y}") case (x, 0): print(f"X={x}") case (x, y): print(f"X={x}, Y={y}") case _: raise ValueError("Not a point") </code></pre> <ul> <li>This is actually the tricky one. x and/or y can change values after this statement if their case is hit.</li> <li>More details in the article, er, appendix.</li> <li>It’s still going to take a while to get used to this, but this appendix is a good start.</li> </ul> <p><strong>Joke</strong></p> <h2><a href="https://devhumor.com/media/true-happiness">true happiness</a></h2>

from Planet Python
via read more