On Thu, May 18, 2017 at 8:06 AM, Christian Gollwitzer <aurio...@gmx.de> wrote: > Am 16.05.17 um 09:53 schrieb Chris Angelico: >> >> On Tue, May 16, 2017 at 5:14 PM, Christian Gollwitzer <aurio...@gmx.de> >> wrote: >>> >>> More likely would be the option to ship a C compiler with Python written >>> in >>> C. For C++ this is way too big, but a pure C compiler can be as small as >>> 1MB. tcc has a liberal license, supports many platforms and gives >>> reasonable >>> (unoptimized) code. >> >> >> To do that, Python would itself have to be compiled with tcc, or else >> all memory de/allocation would have to be funneled through a >> Python-provided API. And that's going to kill performance, I suspect. > > > I don't understand this remark. Why would that be needed? > The C ABI is well defined on the usual systems, and tcc is compatible with > the respective compilers. You can link together objects from tcc, gcc and > icc on Linux /OSX or tcc, MSVC and gcc on Windows without problems. > tcc is *only* the compiler, not a library, so it will call out into the C > library that Python is using. > > tcc even has a "JIT-mode" of operation (libtcc). For Tcl, there exists an > extension which compiles C code to memory and executes directly from there. > The same thing could be done for Python, too.
One of the complaints that bartc raised against clang was that it's not self-contained - that it depends on some other stdlib. Yet he espouses a tiny C compiler that obviously has the same limitation. On my Linux boxes, I can grab GNU libc; but on Windows, where are you going to get the header files and link-time libraries from? Oh right. MSVC. ChrisA -- https://mail.python.org/mailman/listinfo/python-list