:bug: A input cross compatibility in Pyodide (not MicroPython)!

[MongolOS1162]

Checklist

• I added a descriptive title
• I searched for other issues and couldn't find a solution or duplication
• I already searched in Google and didn't find any good information or help

What happened?

🧪 Well, I was testing my app, which had terminal worker attribute and there was devices sepration in input.

1. 🌞 Non COI/COI doesn't supported to modify browsers gives input as Promise/Async
2. 🌥️ COI headers changeable browsers gives input as String

🤚 I had solution,

import builtins, asyncio, inspect
inputs = input
def _input(prompt=""):
    """Asks for user input"""
    result = inputs(str(prompt))
    if inspect.isawaitable(result):
        return asyncio.run(result)
    else:
        return result
builtins.input = _input

🥺 I really hope this could comes by default

Project was I talking and @Ericwasepic127 @MongolOS1162

• Recently, I made PR which is in here.

What browsers are you seeing the problem on? (if applicable)

Mobile Via browser and Chrome

Console info

Additional Context

No response

[WebReflection]

that's an interesting solution but it won't work on MicroPython, although IIRC in MicroPython we don't have such an issue, yet patching globals might have undesired side-effects with 3rd party modules but I'll have a look, thanks for the suggestion.

@ntoll thoughts?

[ntoll]

So this is another example of the perennial "I want to use blocking input in a terminal in a web page" context. Now Pyodide has JSPI support, I wonder if this can be made to work. I was chatting with Damien just yesterday about JSPI support in MicroPython too. My rough thinking - a patched input returns a promise that's resolved with what-has-been-typed and JSPI does the rest. Just thinking out loud.

[WebReflection]

a patched input returns a promise

a no-go on the main thread because you'd need to await that in there. We do have that ability via workers and COI because we can silently, and unobtrusively, block that thread, not the main, never the main.

[WebReflection]

that being said, it's very possible JSPI will be used (if not already) to satisfy asyncio ability to consume generators and promises before running the next line and in there JSPI is ace, or better, the best option, if not the only one, they have.

JSPI works only for the embedded runtime within the embedded runtime constraints, JS cannot use JSPI to fake-block promises, using JSPI from JS side of affairs is still asynchronous, because it cannot block.

all this makes sense to me, yet the elephant in the room is that (imho) nobody should run foreign runtimes on the main thread ever, yet SharedArrayBuffer is still "domed" behind COI requirements, despite Spectre and Meltdown have been both patched at the CPU and mainboard level many years ago, yet the Web is "pretending to save us" from those kind of attacks.

[MongolOS1162]

This was happening on Pyodide, not MicroPython

Well, hope PyScript team can fix that probably.

[MongolOS1162]

I tested on MicroPython too and MicroPython does returns string normally, so this is bug on Pyodide not on MicroPython, @WebReflection and @ntoll

[MongolOS1162]

'a no-go on the main thread because you'd need to await that in there. We do have that ability via workers and COI because we can silently, and unobtrusively, block that thread, not the main, never the main.'

Whenever, if COI headers unable to modify or unsupported browser it returns Promise object because JSPI returns Promise because JSPI doesn't need COI so Pyodide might choose that way to pause input; and when COI could set, then it returns regular string because now it can pause it safely

What You think? @ntoll @WebReflection

[WebReflection]

Whenever, if COI headers unable to modify or unsupported browser

there's not such thing as unsupported browsers, the only to blame in here is Android WebView but that's been solved elsewhere.

JSPI returns Promise because JSPI doesn't need COI so Pyodide might choose that way to pause input; and when COI could set, then it returns regular string because now it can pause it safely

that's true, the question in here is if that suggested workaround would end up using JSPI on Pyodide side.

JSPI itself is not backward compatible, so we need to be sure that suggested change won't affect previous PyScript projects, but that's also granted if they pinned thePyScript version out there.

I'll give it a try 👍

[MongolOS1162]

Ok, hope that works!

[WebReflection]

@MongolOS1162 this is my last warning: please stop commenting with one or more # before each sentence. It is not difficult, you just write your comment, you don't need to format it. Do not start comments with # char.

[Ericwasepic127]

OKOK, I will not use (it's my main account)