On Tue, May 16, 2017 at 11:19 AM, Deborah Swanson <pyt...@deborahswanson.net> wrote: > Chris Angelico wrote, on Monday, May 15, 2017 2:58 PM >> You seem to be of the opinion that some day, binary >> executables will be compiled using pure Python code. > > Well, my naive opinion is that they should be. But it was just one > message back that I learned some Python built-in modules are at least > partially written in C. I didn't know that, nor did I know or suspect > that installation files for official Python releases likely contained C > compilers. This raises a lot of questions for me, though it probably > would be better for me to read and think about them on my own before > coming back here with anything.
It is possible to build a compiler for Python in Python. (See: PyPy.) The most normal way to build extension libraries is with C, though, because that's what most lower-level libraries depend on. For example, suppose you want to build a GUI toolkit for Python, using the GTK library. You can't easily do that in Python (technically you *can*, using ctypes, but ctypes is itself implemented in C), so you'll end up writing a C extension library. > I'll accept that, though I still don't quite understand the recent > dependence on Visual C++, after Python has been building its releases > with the tools you and others mention from the beginning until shortly > after the first 3 build was released, and the requirement has been so > much deeper since 3.4.3, that Python (apparently) can no longer use the > Visual C++ compiler built into XP. These are just things I wonder about > since these new requirements put a real crimp in what I'm currently able > to do, and I wonder how they will change Linux too. Again, lots of stuff > for me to pursue on my own here. An installed Python does not itself depend on MSVC. It's only when you need to compile additional C code - another Python module that is implemented in C - and you can't pick up someone else's precompiled version. It's not a new requirement; although you could perhaps argue that pip's presence in the standard library has made this a lot more likely to come up, as previously, you wouldn't have been able to install this module *at all* without fiddling around manually. > No, with what I've learned today, I certainly would agree that Python > has its beholdens, and likely always will. The bright side is that > Python at least doesn't appear to be unduly constrained in how it uses > the C/C++ code it does. I just hope that it continues to be kept to a > minimum, but I guess I'm just a stinking purist about some things. Actually, I'm glad that most of Python's core is implemented in C, because it means my code runs faster :) It's all thoroughly unit-tested, and I'm happy with it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
