3 ms·

Pygame is all this is. I'm not saying that it's the only way. It's probably one of the worst ways in my humble opinion, though I can't really say that without u

Pygame is all this is. I'm not saying that it's the only way. It's probably one of the worst ways in my humble opinion, though I can't really say that without understanding their vision for the project tbh. Should I assume they are looking at scratching every single line of code they've written for this and restarted? Why would I make that assumption? I don't want to quibble with you. My only point here is that an all-python user space is a significant undertaking if you are willing to acknowledge the scope of what the user space actually entails. It's totally doable, but this project isn't even a step in the direction of solving those problems. It's a totally different thing. Depending on the objective in a "python only" operating system, I may be inclined to strongly advise not trying to reimplement everything in python. The nature of C is such that you can write a C compiler in C, compile it, throw away the source code, and use the compiled binary for the new compiler to start developing a new compiler for C. But you can't like, make a python interpreter for python, in python, delete CPython, and then use the python version. It is dependent on CPython. And so, to build it, it's dependent on GCC, make, a shell, etc. These are great tools. I think you should keep them, and define a specific surface area that python interfaces with. That's all I'm sayin'.

pjmlp 6y ago
Sure you can, that is the whole goal of PyPy, IronPython, Jython, Python on GraalVM, Python on OpenJ9, CircuitPython and plenty of other attempts. Anyone that understands compilers knows one can write language X in X. In fact, "Writing Interpreters and Compilers for the Raspberry Pi Using Python" does exactly that. We can nuke CPython and there is plenty of Python code that would still run without problems.
- bonestormii_ 6y ago
  I'm sorry man, but you sound incoherent to me. You can write a compiler for python in python--but it still needs the original cpython (or jython, or ironpython, or pypy, etc.) to run, because there is no compiled binary produced by your python code. You can write a compiler for any language using python, but you need one of the interpreters you mentioned, and you can't throw it away unless it produces a binary. Maybe Cython can do this. But if it needs an interpreter to run, you'll have to keep the interpreter around as a non-python dependency. But who cares? Unless you rewrite a Pygame from scratch, or replace it with another graphics library, in which case you need to rewrite snakeware from scratch, none of this is relevant here. It's just insane. You are proposing rewriting entire language runtimes and/or graphics engines to preserve 1400 lines of python code (mostly a menu, a calculator, and a game of snake), with the supposed goal of creating an all python user space, and dismissing it as "Who says you can't do it?". I'm not saying it's impossible, but it makes no sense. You'd be better off starting over and taking this on with a different strategy. If your end goal is an all Python user space linux distro that actually works like linux, this project is a non-starter without being totally reimagined with virtually 0 reuse of the code that's there even at a conceptual level. You wanna rewrite pygame or python's compiler? Be my guest! It has nothing to do with your supposed objective though. At the very least, you would need to get out of the pygame window simulation, start using a standard graphics compositor, and replacing existing utilities with python alternatives to make this work. But again, even CPython, Jython, PyPy, etc. will need to remain. Maybe Pygame can be made to work with PyPy, in which case you get close to what you want--but it's still a C extension, not python. And that's your graphics renderer. So why not just use Wayland or something then? I think the quest for language purity at the OS level is a fun dream to pursue, but you need to decide where to cut it off in terms of scope and how to implement the scope you choose.

pjmlp 6y ago

Sure you can, that is the whole goal of PyPy, IronPython, Jython, Python on GraalVM, Python on OpenJ9, CircuitPython and plenty of other attempts. Anyone that understands compilers knows one can write language X in X. In fact, "Writing Interpreters and Compilers for the Raspberry Pi Using Python" does exactly that. We can nuke CPython and there is plenty of Python code that would still run without problems.

bonestormii_ 6y ago
I'm sorry man, but you sound incoherent to me. You can write a compiler for python in python--but it still needs the original cpython (or jython, or ironpython, or pypy, etc.) to run, because there is no compiled binary produced by your python code. You can write a compiler for any language using python, but you need one of the interpreters you mentioned, and you can't throw it away unless it produces a binary. Maybe Cython can do this. But if it needs an interpreter to run, you'll have to keep the interpreter around as a non-python dependency. But who cares? Unless you rewrite a Pygame from scratch, or replace it with another graphics library, in which case you need to rewrite snakeware from scratch, none of this is relevant here. It's just insane. You are proposing rewriting entire language runtimes and/or graphics engines to preserve 1400 lines of python code (mostly a menu, a calculator, and a game of snake), with the supposed goal of creating an all python user space, and dismissing it as "Who says you can't do it?". I'm not saying it's impossible, but it makes no sense. You'd be better off starting over and taking this on with a different strategy. If your end goal is an all Python user space linux distro that actually works like linux, this project is a non-starter without being totally reimagined with virtually 0 reuse of the code that's there even at a conceptual level. You wanna rewrite pygame or python's compiler? Be my guest! It has nothing to do with your supposed objective though. At the very least, you would need to get out of the pygame window simulation, start using a standard graphics compositor, and replacing existing utilities with python alternatives to make this work. But again, even CPython, Jython, PyPy, etc. will need to remain. Maybe Pygame can be made to work with PyPy, in which case you get close to what you want--but it's still a C extension, not python. And that's your graphics renderer. So why not just use Wayland or something then? I think the quest for language purity at the OS level is a fun dream to pursue, but you need to decide where to cut it off in terms of scope and how to implement the scope you choose.