#501 A Nod to Sir-Mix-Alot cover art

#501 A Nod to Sir-Mix-Alot

#501 A Nod to Sir-Mix-Alot

Listen for free

View show details

Season's Savings | £0.99/mo for 3 months

£5.99/mo after 3 months - terms apply. Cancel monthly
Topics covered in this episode: Nod: pause your Python program and open a notebook at any linePolars 2.0 ships: streaming engine by default, spill-to-disk, and a row-order gotchadjango-cachalot caches your ORM queries and invalidates them for youTowards async transactions in DjangoExtrasJokeWatch on YouTube About the show Sponsored by us! Support our work through: Our courses at Talk PythonConsulting from Six Feet Up Connect with the hostsMichael: Mastodon / BlueSky / X / LinkedInCalvin: Mastodon / BlueSky / X / LinkedInShow: Mastodon / BlueSky / XJoin us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Tuesday at 7am PT. Older video versions available there too.Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it. Michael #1: Nod: pause your Python program and open a notebook at any line Nod (Notebooks-on-Demand) is a JupyterLab extension by Eric Rawn that drops a notebook into a running Python program. Add a notebook() call anywhere, run the program with nod, and execution pauses there with a notebook containing all variables at that point in the call stack. Edits go back to the source file with a button, with cells converted to code and markdown to comments via Jupytext. It answers the classic 'this would be easier in a notebook' debugging moment without copying snippets out to files.Like a breakpoint with a notebook inside: the left panel walks the call stack and notebook state switches with itInstall is pip install nodpy plus nod --install-kernel, then run with nod python -m myfileThe round trip back to source is the differentiator; markdown cells become comments, cells become newlines, and notebooks are disposable since the source file recreates themnodLog() stashes variable values across calls to explore later; the article also pitches notebook() for stepping through AI-generated code line by lineEarly stage: repo from December 2025 with 16 stars and essentially one contributor, so expect rough edges Calvin #2: Polars 2.0 ships: streaming engine by default, spill-to-disk, and a row-order gotcha Polars 2.0 released Oct 6, 2026 (Ritchie Vink). The post says it's "not intended to be a big feature release", but it bundles a few big changes.LazyFrame.collect now defaults to the streaming engine, with large memory and speed gains on most queries.Breaking: streaming doesn't guarantee row order for join, group_by and unpivot. Use maintain_order=True if order matters. This is why it's a major version.Out-of-core (spill-to-disk) is on by default. It spills at about 80% of RAM ("may need tuning") with a 64 GB default disk budget. It covers sort, window functions and many expressions. Joins and group-bys are planned, not shipped.The new native Map dtype (Arrow MapType) replaces the old List(Struct(key, value)) reading. It comes with map.get, map.contains_key, map.len, map.keys and map.values.Stricter by design: errors should surface up front and implicit handling of data mismatches is opt-in. collect_schema() catches schema mismatches without reading data.SQL is now a first-class interface, with join reordering, better common-subplan elimination, and dynamic predicates/bloom filters.Benchmarks are self-run TPC-H/TPC-DS derived numbers against DuckDB 1.5.6 and 2.0 alpha, and DataFusion 54. They are not official TPC results.Polars was fastest on all but one benchmark. At 192 threads its constant overhead hurts small data (SF10 TPC-DS is 1.8x slower), and a fix is hoped for in the next release.Roadmap, not released: out-of-core joins and group-bys, better scaling at high core counts, Polars Cloud, and early GeoPolars work.Upgrade guide: https://docs.pola.rs/releases/upgrade/2/ Michael #3: django-cachalot caches your ORM queries and invalidates them for you django-cachalot is a Django package that caches ORM queries and invalidates them automatically when the underlying data changes. Install it, add one line to INSTALLED_APPS, and read queries run through your cache backend with no code changes. The trick is that it caches whole tables, so any write flushes that table's cached queries, making it a strong fit for read-heavy sites and a poor one for frequently updated tables. It supports Django 4.2 through 6.1 and Python 3.8 to 3.14. ORM caching that normally takes careful engineering drops in with pip install and one settings line, invalidation included.Near-100x on joins: the README reports nearly 100x speedups for initial deployments heavy on select_related and prefetch_related.It caches the entire table, so a hot table with frequent writes invalidates constantly; docs suggest staying under 50 modifications per minute and mixing in cache-machine for hot paths.Setup is two lines, plus caveats: sync clocks across servers sharing one cache, and run a manage.py command after restoring a database outside Django. Calvin #4: Towards async transactions in Django Carlton ...
adbl_web_anon_alc_button_suppression_t1
No reviews yet