Harald Massa said:
I propose you should take a look at PyPy first.
PyPy is an attempt to realise Python in Python. Because "IN THE END" your
Operating System must run on existing hardware. And there is a step between
Python and Assembler...
With standard CPython it is C-language, with Jython it is Java.
But there can be C-Errors in Python and C-Errors within Java ... so to get
"only Python", you need a PythonPython first.
Am I wrong?
Yes I think so. PyPy is a nice project, but it is a kind of all or
nothing project. What is needed is something like Prothon, but even
smaller.
Prothon is using a set of separate dlls (f.e. dict.dll, list.dll etc.)
to provide the basic objects. This is a lot better than what Python is
doing at the moment, because Python depends on one megadll
(pythonxx.dll) for these objects.
The problem with this approach is that all objects have to be compiled
using the same compiler, while it would theoretically be possible to
write one dll using C, another using Lisp another using assembler and
another using something else.
Prothon theoretically could do that, but it loads the basic dlls the
moment the interpreter is started, which makes it dependent on having
all these dlls available (and possibly all dlls need to be compiled
using the same compiler, I don't know about that).
What is needed for Python to come closer to the OS and to enable it to
advance faster is a bootstrapping interpreter which basically only
provides a ctypes alike functionality that enables it to import a set
of basic Python object dlls in the same way as if it were standard
operating system dlls. It would make no difference for the interpreter
if it imported dict.dll or for example kernel32.dll, but of course
this strategy would introduce needing to have *some* dlls imported
before all others in order to provide basic functionality. This is
currently necessary for the __future__ extension too so there is a
precedent already. I expect such a beast to have a footprint of about
100k.
There would be no problems with Python extensions needing to be
compiled with a certain C-compiler since all dlls would be required to
conform to the dlls of the operating system.
This would bring Python a lot closer to seamless interaction with the
operating system and enable it to eventually turn into not a
completely separate operating system but into something akin to Cygwin
(which is a kind of Linux running under Windows).
Another advantage would be that it would be possible to update Python
in smaller steps, for example only a newer dict.dll, this time a dll
written in assembler or even in Lisp. For systems that don't have this
compilers older dict.dll files would still be available.
Some Python scripts could have a really small footprint as if it were
Lua scripts because we only need to provide those dlls that the script
uses, sometimes only dlls that the operating system already has, or
dlls that are in Cygwin, Visual Basic or C# and which are freely
available on the net. In the latter case probably some flexible dll
loader functionality would be necessary, hence the need for ctypes.
Or we could compile the necessary dlls on the fly using a Python
compile-to-os-specific-dll script that only needed a few standard
Python dlls itself.
Since I'm not an OS-guru or even know a lot about the lower level
details (though I have been able to write and compile extensions in C)
I might be wrong about the feasibility of such a project (maybe it can
be done but the standardization of dll interfaces would be
prohibitively difficult given Pythons dynamic and platform independent
development cycle) but I remain confident that this is the way to go.
(I'm Dutch you know, so I can't be proven wrong unless you've got a
timemachine, I have used mine to post the same kind of idea about half
a year ago and I *will* use it to retroactively fix *this* post in
case there are problems with it
)
Anton
