Deborah, I get the feeling you don't understand the architecture/implementation of Python. The (C)Python interpreter is written in C. A number of the built-in modules are least partially written in C. As such, C is a natural integration point for extensions. Many, many third-party extensions are written completely or partially in C or C++. If you're going to install Python or these modules from source, you need a C or C++ compiler. On Windows, this tends to be MSVC. On Linux, GCC or clang. On OS X, clang.
You may consider C & C++ to be lesser languages, but Python's built upon those "lesser" languages. Personally, I love both C++ & Python. You need to know when to use the write tool for the job (hammer vs screwdriver). Comparing Python to MSDOS is comparing apples to oranges. MSDOS is not a language. It is an operating system (albeit a bare-bones, single-user one). Regards, Nathan On Mon, May 15, 2017 at 4:01 PM, Deborah Swanson <pyt...@deborahswanson.net> wrote: > Chris Angelico wrote, on Monday, May 15, 2017 11:22 AM > > > > On Tue, May 16, 2017 at 4:12 AM, Deborah Swanson > > <pyt...@deborahswanson.net> wrote: > > > It continues to amaze me that Anaconda and Python.org, probably the > > > two biggest distributors of official Python builds, are now relying > on > > > Visual C++. Why can't Python developers write the entire setup and > > > installation code in Python? Surely Python has the required > > > functionality, and it seems more than a little demeaning for Python > to > > > be using Visual C++ as a crutch. > > > > Are you suggesting that a C compiler should be written in > > Python? Because you're dealing with an extension library. > > It's not written in pure Python. That's why it needs a C > > compiler. While it is certainly possible to write a C > > compiler in Python, it is unlikely to outperform the existing > > popular compilers (gcc, clang, msvc, etc), which have had > > many years of expertise poured into them. > > I don't know much about extensions yet, but I think I can see what > you're saying. It probably is a shortcut for volunteer developers to use > existing C/C++ code where they can, rather than writing all of it from > scratch in Python. > > But I'm a little more mystified that official Python builds are leaning > on Visual C++ (and that's what the crutch comment was primarily aimed > at). Perhaps they're just as resource needy as the extension developers > are and new requirements have come up as Python 3 progresses that they > don't already have Python build and installation tools written and > tested for. I'd be willing to step into that void when my Python skills > are equal to the task (and my health permitting, of course). But that > would be years from now, and maybe someone else will step up before > then. I'm really thinking that build has languished far behind the rest > of the language's development for way too long. > > > None of this applies if you are actually depending on a pure > > Python module, which *can* be installed without a C compiler. > > Visual C++ is not a crutch but a critical part of the build process. > > > > ChrisA > > I'll still think of it as a crutch for official Python builds, but I can > see your point for extension developers. > > Maybe I have more pride in the Python language than is right and proper, > but I do think it would be worth the relatively small investment to make > and start growing Python's own build and installation tools asap. Python > will be the reigning Queen of coding languages someday. Certainly seems > like she should have all her own working parts and be beholden to no > one. ;) > > Microsoft saw the need for build and installation teams very early on, > and now everyone depends on what they made. > > And yes, Windows and all Microsoft software from thence forward was > primarily made with C/C++, because MSDOS was appallingly incapable of > meeting the challenge and that's all they had before Windows. > > Python has a lot more than MSDOS ever dreamed of, and that's what seems > demeaning to me that Python is piggybacking on a lesser language, > because their need to do so is so infinitesimally less than Microsoft's > need was to move on from MSDOS. And I think the day is coming that > Microsoft will be too much of a dinosaur (like IBM has become) to > continue meeting the needs of evolving languages. Better to get going on > our own tools, the sooner the better, in my opinion. > > Deborah > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list