Chris Angelico wrote, on Monday, May 15, 2017 2:58 PM > > On Tue, May 16, 2017 at 7:01 AM, Deborah Swanson > <pyt...@deborahswanson.net> wrote: > > 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. > > > > > > 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. ;) > > 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. > Maybe > that's true; maybe it's not. The point is, though, that high > performance binaries can't be created without a LOT of > expertise relating to the OS, the standard library, the CPU > architecture, etc, etc, etc. That expertise has been > coalesced into existing C compilers (I mentioned gcc, clang, > and msvc earlier; others also exist but those are the most > popular), and throwing that out means having a subpar Python. 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. > Perhaps a future version of gcc will be implemented in > Python. Would you then say that Python is beholden to no one? > You would still need to have a C compiler installed in order > to compile extension modules. It's too big to include with > every single Python installation. So you'd have the same > situation even then. > > ChrisA 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. Just another pretty fantasy smashed. So it goes. It's definitely better to have broken fantasies to feel bad about having, and to know the truth. Deborah -- https://mail.python.org/mailman/listinfo/python-list
