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

Reply via email to