How about we use the interpreter as shared reference instead? #1436
WebReflection
started this conversation in
Proposals
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
While working on this PR #1435 I've realized we inevitably couple a single
interpreter
to the<py-script>
custom element definition due to themake_PyScript
closure that is used to reference such interpreter.What's the issue
The custom elements registry is globally shared, meaning that once a
py-script
element has been defined (aka registered) any other attempt to re-define such element name will throw right away.Accordingly, in no circumstances the
interpreter
used asmake_PyScript
argument will ever be different from the very initial one we pass along the very first time we define such class.While this could have been an intended behavior, it's unclear why any other utility in
pyscript.ts
accepts an interpreter, when the custom element logic already bases its execution around a single possible interpreter that nobody can hot-swap or change during a page session.Since there's some work in progress around MicroPython, dare I say we should never bind any logic to a specific interpreter created at some point in time, rather share the currently used interpreter through the handy module system we use already to define our files.
In doing so, we can simply define the interpreter before registering the custom element, but also it's not clear why
make_PyScript
is a callback, because if it's invoked more than once, we'll have errors due unique registry nature.Because modules in JS are never executed more than once, I'd like to propose the creation of pyscript.ts or most of its logic a part and outside any callback, allowing it to reach the current chosen/running interpreter and use it whenever it's convenient, specially if we'd like to be able to bootstrap runtime created attributes or nodes with
py-*
specific attributes, because there's no way otherwise to retrieve the interpreter if not by "leaking" the last one used internally in that very same file ... which is ugly, but most importantly, underlines to me our dance around the interpreter is not very clean, architectural speaking, or at least it doesn't really play well with runtime changes that could happen to any element at any time on a page, which looks like desirable and indeed it represents the work I am doing in that specific PR.What are your thoughts? Should we decentralize the
interpreter
reference within its own module and import such module to grab the current interpreter instead, any time it's needed to evaluate some Python code?Beta Was this translation helpful? Give feedback.
All reactions