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:
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.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.
def __getattr__(name): pass at any Python module level automatically allows me to intercept anything the importer is trying to access 🤯
server.py module in pure Python that does pure Python things !!!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!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 therelambda 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’ worldt 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 errorMy 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 👋