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

#389: More OOP for Python?

Published Mon, Jun 24, 2024, recorded Mon, Jun 24, 2024
Watch this episode on YouTube
Play on YouTube
Watch the live stream replay

About the show

Sponsored by ScoutAPM: pythonbytes.fm/scout

Connect with the hosts

Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Tuesdays at 10am 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: Solara UI Framework

  • via Florian
  • A Pure Python, React-style Framework for Scaling Your Jupyter and Web Apps
  • Solara lets you build web apps from pure Python using ipywidgets or a React-like API on top of ipywidgets.
  • These apps work both inside the Jupyter Notebook and as standalone web apps with frameworks like FastAPI.
  • See the Examples page.
  • Based on Reacton
  • By building on top of ipywidgets, Solara automatically leverage an existing ecosystem of widgets and run on many platforms, including JupyterLab, Jupyter Notebook, Voilà, Google Colab, DataBricks, JetBrains Datalore, and more.

Brian #2: Coverage at a crossroads

  • Ned Batchelder is working on making coverage.py faster.
  • Includes a nice, quick explanation of roughly how coverage.py works
    • with trace function and arcs used for branch coverage.
  • And how trace slows things down for lines we know are already covered.
  • There are cool ideas from SlipCover that could be applicable.
  • There’s also sys.monitoring from Python 3.12 that helps with line coverage, since you can disable it for lines you already have info on.
    • It doesn’t quite complete the picture for branch coverage, though.
  • Summary:
    • jump in and help if you can
    • read it anyway for a great mental model of how coverage.py works.

Michael #3: “Virtual” methods in Python classes

  • via Brian Skinn
  • PEP 698 just got accepted, defining an @override decorator for type hinting, to help avoid errors in subclasses that override methods.
  • Only affects type checkers but allows you to declare a “link” between the base method and derived class method with the intent of overriding it using OOP. If there is a mismatch, it’s an error.
  • Python 3.12’s documentation
  • Makes Python a bit more like C# and other more formal languages

Brian #4: Parsing Python ASTs 20x Faster with Rust

  • Evan Doyle
  • Tach is “a CLI tool that lets you define and enforce import boundaries between Python modules in your project.”
  • When used to analyze Sentry’s ~3k Python file codebase, it took about 10 seconds.
  • Profiling analysis using py-spy and speedscope pointed to a function that spends about 2/3 of the time parsing the AST, and about 1/3 traversing it.
  • That portion was then rewritten in Rust, resulting in 10x speedup, ending in about 1 second.
  • This is a cool example of not just throwing Rust at a speed problem right away, but doing the profiling homework first, and focusing the Rust rewrite on the bottleneck.

Extras

Brian:

  • I brought up pkgutil.resolve_name() last week on episode 388
  • Will we get CalVer for Python?
    • it was talked about at the language summit
    • There’s also pep 2026, in draft, with a nice nod in the number of when it might happen.
      • 3.13 already in the works for 2024
      • 3.14 slated for 2025, and we gotta have a pi release
      • So the earliest is then 2026, with maybe a 3.26 version ?
  • Saying thanks to open source maintainers
    • Great write-up by Brett Cannon about how to show your appreciation for OSS maintainers.
      • Be nice
      • Be an advocate
      • Produce your own open source
      • Say thanks
      • Fiscal support
    • On topic
      • Thanks Brett for pyproject.toml. I love it.

Michael:

Joke: Tao of Programming: Book 1: Into the Silent Void, Part 1


Want to go deeper? Check our projects