24th of April, 2026

Long time no see, right? Well, here’s the thing: we had planning week and I am not here to share all the details, yet there’s been OSS effort here and there so here’s the summary:

• we’re removing (so far) useless runtimes in the polyscript project, because:
  • we had zero feedback, use cases, contact, anything, from the community, and since other runtimes keep breaking now and then but we’re busy moving PyScript forward, we decided that it’s time to “let it go” and focus on what we use and need daily, instead of “fairy tales” about abstraction
  • for the PyScript use case, dropping code is always welcome because everyone wins with less shipped code to deal with. On the other hand, we have this side effect: once PyScript is in, people can abuse the <script> tag in unplanned ways … enough said?
• fixes around pyscript.web landed
• we’re testing the ability for PyEditor to shine more than ever and we’ve been successful to date. If you’ve followed recent packages.pyscript.net repository updates, we’re adding examples for each package we support out of the C-Python (or better, Pyodide) ecosystem. Those examples end up in the JSON response and each example can have a setup entry but always a code one. We’re automating things out of our editor; we’ll adjust as we need, and we might even rewrite it for new use cases we hadn’t thought of. If you feel like contributing examples that show only Python code—no PyScript, no Pyodide—please help us help you (and others) via proper examples: abstraction (fake it until it works) on setup.py, real code on code.py!
  • we have only pandas examples right now, but we’re planning to grow that sooner than later!
• one way to deliver PyEditor in the wild is to use a self-aware Web Component, which inevitably ends up being customElements-based. If you know me, I’m the author of every reliable, battle-tested Custom Elements polyfill out there since the beginning of time (V0 and V1), so who’s better placed to write tools that can inherently deal with all the Web’s internal shenanigans and gaps developers have been asking about forever? … Guess who. In the meantime, ShadowObserver landed in my repos, and I’m planning to use it all the way down and behind anything that needed that to date:
  • you explicitly pass a shadow property to the MutationObserver-like reference when you want to observe a node
  • that automatically propagates through the whole shadowRoot node, whether it’s 'open' or 'closed'
  • your library can hook into anything that needed such ability to date but it likely did it wrong
  • no more patches of Element.prototype.attachShadow that break other patches
  • no more thinking about “what if there are closed shadow roots on this page?”
  • vendors are discussing this and (IMHO) needed a working proof of concept that would let them test the proposal
  • if nothing happens at the standards level, we have a solution 🥳

That’s it from me today. I just wanted to assure you we are safe and sound; we’re working on things that matter to everyone. If anything internal needs changes or updates to our PyScript and plugin offerings, you will all benefit from that, so everybody wins 👋