Andrea Giammarchi's Standup
Archive

24th of March, 2026

I am still working on a dedicated rewrite that should make the Pyscript & Positron story a “love one”, but there’s still work to do … that being said:

  • offliner - we already publish PyScript with its offline pre-bundled capability, yet we thought that having a way to hook into any PyScript app and automatically create an offline-first/ready version of such app would be ace! We experimented with an approach that seems to work wonderfully, it’s called offliner (not by accident) and if curious about it, here there’s a video I made today about how to use it. This package will be useful, if not essential, to also get our Positron story out in the easiest possible way, out of any alredy published PyScript project.
  • reflected-ffi - today I’ve merged the latest effort around reflected-ffi and published it as it is. From now on, the Python variant will be on track with the JS one. This module is the one providing a way to reflect from one world/PL to another, how things should be shaped. I’ve removed the JS to Python conversion because I think that’s something that is broken in one way or another, for one language or another. As an example, I was bringing Python set or tuple to JS without any counter-meaningful usage, and JS symbol primitives to the Python world … I think there could be some value around that approach, yet I believe too much translation makes everything ambiguous by design on one side or the other of the equation. Right now the original JS reflected FFI remains, with minor fixes too, and Python reflected FFI is currently focused on Python reflected FFI related things only. Example: the __enter__ trap is needed for cases such as with open('file.txt') as f: and the __exit__ too, and there’s no way to mimic or translate these cases meaningfully from one PL to another. One thing I’ve learned over time is that the driver should be in charge, not the gluer (JS in our case) … so these things should be the other way around: Python decides what JS should do, as opposed to reducing its capabilities due to JS incompatibilities around syntax and/or potentials.
  • no direct npm - I am actually publishing tar.gz pre-bundled and optimized versions of my libraries out of GitHub and/or npm and I’ve thought: “wait a minute, isn’t npm also already based on tar.gz files?” … well, yes and no … I have tested direct npm download of libraries but if not pre-bundled and optimized, the dance is pretty unusable: lesson learned, I’ll keep publishing or at least pushing to GitHub some tarball whenever it’s needed.
    • opportunity - it occurs to me there is no tool able to, once defined an entry point, fetch and combine all requirements and produce a single JS file (or a list of modules to import at runtime) already optimized by all means … CDNs do this on their own way, yet it’s all CDN based, no live-to-local transformation so far … please let me know if I’ve missed such tool because it might be essential or extremely useful to me to move forward with some topic, thank you!
  • Python module runtime - it took me a while to realize that def __getattr__(name): pass at any Python module level automatically allows me to intercept anything the importer is trying to access 🤯
    • runtime cache for already accessed fields
    • no need to use JS to simulate that behavior via a Proxy
    • easy to define a server.py module in pure Python that does pure Python things !!!
    • … I am still not super confident this could replace, simplify, improve tons of PyScript related topics, but it will surely help me simplify the story around Positron!
  • t-string discussions - PEP750 is out and running, already in MicroPython, soon in Pyodide, surely out in Python 3.14. The discussion is around the fact that people aren’t really grasping, understanding, or even liking, what it offers and there are discussions around what we could do to make that standard a really desirable one. My current opinion around this topic is that, while I’ve warned everyone I could before it became a standard why the way it was shipping wasn’t good or ideal for DX purposes, it shipped the way it is … which is “ok” but still …
    • every signature that accepts t as an argument is variadic for no real-world use case whatsoever: fn'...{'ok'}...' is a sealed signature, easier to read, scan, parse, execute … no *args, **kwargs involved ever, it expects a template as unique entry point, and that’s it!
    • every t usage requires a wrapper … it’s a common understanding in programming that repeating every time the same intent means “macros” … Rust, C++, you name it … t string could’ve been a macro for function definitions, it became “a traveling primitive” for good reasons though, it’s the same in JS, but functions meant to deal only with a single template signature and arguments as interpolation in JS are the only implementations you’ll ever find out there
    • IDEs cannot easily distinguish between a lambda x: t'...{x}...' meant to land within html or svg or sql content; Python created a problem that was solved already in the JS runtime and IDEs’ world
    • users will fail at remembering a function accepting a t string and a t string only, such as html(t'...') might make t an evil/obscure feature that is disaster prone for productivity and actual real damage reasons, when the last person hired wrote f instead of t believing t was an error

My current hope is that Python will listen this time, after shipping t strings in its form, and we’ll have something as cool as aliases for t:

@template_string
def html(template.Instance): pass

# see? no html(t'...') ... just html'...'
html'<h1>Hello, finally, t-string!</h1>'

so that it’s clear that a function must be used as the t-string equivalent, its signature will be sealed, people won’t need to remember to wrap strings after t (or even worse, or by accident, f) and we’ll have some powerful primitive that will flourish as much as template literal tags in the JS world flourished over the last 10 years … there is hope!

That’s it, I am still working on putting all pieces together, but because today there were new discoveries, discussions and solutions, I wanted to write down where I am, hoping that next time I update this space I can show you what I’ve built instead 👋