Requested changes to python environment.
The python environment allows very little real-world interaction, making it not very fun to make programs. Earlier today I thought "what if I made Tetris using ASCII characters?", then I remembered that the python environment requires pressing enter for the program to receive the input, and pressing enter after every single move would be very hard an annoying. In the python environment as it stands, real-time inputs of any sort are impossible because it require pressing the enter key to submit content to the input() function. I propose several additions to the python environment, of various complexity.
Starting off with simple, small changes that would have a major impact:
1. Real-time-arrow-inputs. The simplest way to implement this would be to make the arrows keys, when pressed on the python output environment, postMessage to the worker, which can then call preset functions such as `def onarrowkey(direction)`.
2. Real-time-inputs. The above could be extended to allow the user to see what is being typed to the python program before the enter key is set - defining, for example, a preset getPartialInput() function, that would postMessage out of the working requesting what is typed on the current input line.
Those are both simple but less ideal solutions.
3. The ultimate upgrade to the python environment that would make it actually useful and fun to learn, and even applicable to the real world, would be to run the environment using Pyodide >= version 2.26, where they added support for Pygame. Pygame is a python graphics library, similar to Processing.js, and unlike Processing.js, it has the added benefit of being both modern and very much still used. See release notes here https://blog.pyodide.org/posts/0.26-release/, and a demo of python code running Pygame programs here https://ryanking13.github.io/pyodide-pygame-demo/. This alone would by itself add real time key inputs, graphics, and everything else making it fun to program in.
5. DOM access. If pygame isn't added, *some* way to visualize output besides text is desperately needed. Putting the terminal on a DOM layer that the worker can access to set HTML elements would be very useful, even if bindings are not created to access it. Pyodide supports running javascript, and users like myself would turn this DOM access into graphics libraries with python bindings.
6. Colored output support. This is less important but it would help with text-only programs. It would be done by implementing respect for ANSI escape sequences that python uses to tell a terminal what color to change the printed text to, see https://stackoverflow.com/questions/287871/how-do-i-print-colored-text-to-the-terminal. Several ANSI to HTML processors already exist, such as https://github.com/sensiolabs/ansi-to-html
1, 2, and 6 could be implemented in less than 10 minutes. 3 has a lot of public information and tutorials now about how to implement, it just needs to be sandboxed properly which the environment may or may not already be setup for. 5 might require changing the worker setup a bit but is nonetheless possible.
Iniciar sesión para dejar un comentario.