#275: Airspeed velocity of an unladen astropy

Published Wed, Mar 16, 2022, recorded Tue, Mar 15, 2022

Watch the live stream:

Play on YouTube

Watch the live stream replay

About the show

Sponsored by Microsoft for Startups Founders Hub.

Michael #1: Async and await with subprocesses

by Fredrik Averpil
People know I do all sorts of stuff with async
Lots of cool async things are not necessarily built into Python, but our instead third-party packages
E.g. files via aiofiles
But asyncio has asyncio.create_subprocess_exec
Fredrik’s article has some nice examples
I started using this for mp3 uploads and behind the scenes processing for us

Brian #2: Typesplainer

Emily #3: Ibis Project

via Marlene Mhangami
“Productivity-centric Python data analysis framework for SQL engines and Hadoop” focused on:
- Type safety
- Expressiveness
- Composability
- Familiarity
Marlene wrote an excellent blog post as an introduction
Works with tons of different backends, either directly or via compilation
- Depending on the backend, it actually uses SQLAlchemy under the hood
There’s a ton of options for interacting with a SQL database from Python, but Ibis has some interesting features geared towards performance and analyzing large sets of data. It’s a great tool for simple projects, but an excellent tool for anything data science related since it plays so nicely with things like pandas

Michael #4: ASV

via Will McGugan
AirSpeed Velocity (asv) is a tool for benchmarking Python packages over their lifetime.
Runtime, memory consumption and even custom-computed values may be tracked.
See quickstart
Example of astropy here.
Finding a commit that produces a large regression

Brian #5: perflint

Anthony Shaw
pylint extension for performance anti patterns
- curious why a pylint extension and not a flake8 plugin.
I think the normal advice of “beware premature optimization” is good advice.
But also, having a linter show you some code habits you may have that just slow things down is a nice learning tool.
Many of these items are also not going to be the big show stopper performance problems, but they add unnecessary performance hits.
To use this, you also have to use pylint, and that can be a bit painful to start up with, as it’s pretty picky.
- Tried it on a tutorial project today, and it complained about any variable, or parameter under 3 characters. Seems a bit picky to me for tutorials, but probably good advice for production code.
- These are all configurable though, so you can dial back the strictness if necessary.
perflint checks:
- W8101 : Unnessecary list() on already iterable type
- W8102: Incorrect iterator method for dictionary
- W8201: Loop invariant statement (loop-invariant-statement) ←- very cool
- W8202: Global name usage in a loop (loop-invariant-global-usage)
- R8203 : Try..except blocks have a significant overhead. Avoid using them inside a loop (loop-try-except-usage).
- W8204 : Looped slicing of bytes objects is inefficient. Use a memoryview() instead (memoryview-over-bytes)
- W8205 : Importing the "%s" name directly is more efficient in this loop. (dotted-import-in-loop)

Emily #6: PEP 594 Acceptance

“Removing dead batteries from the standard library”
Written by Christian Heimes and Brett Cannon back in 2019, though the conversation goes back further than that
- It’s a very thin line for modules that might still be useful to someone versus the development effort needed to maintain them.
Recently accepted, targeting Python 3.11 (final release planned for October 2022, development begins in May 2021. See the full release schedule)
Deprecations will begin in 3.11 and modules won’t be fully removed until 3.13 (~October 2024)
See the full list of deprecated modules
Bonus: new PEP site and theme!

Extras

Brian: Michael:

Emily:

Jokes:

Full transcript