On Mon, Feb 26, 2018 at 8:57 PM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > On Sun, 25 Feb 2018 20:22:17 -0800, Rick Johnson wrote: > >> So of course, speed is not and should not be the >> primary concern, but to say that execution speed is of _no_ concern is >> quite absurd indeed. > > I'm pretty sure that nobody here has said that speed is of no concern. > > Rather, I would argue that the position we're taking is that *in general* > Python is fast enough for the sorts of tasks we use it for (except, of > course, when it isn't, in which case you have our sympathy, and if we can > suggest some solutions we will). > > Of course we'd take speed optimizations if they were free, but they're > never free: > > - they often require more memory to run; > > - they usually require more code, which adds to the maintenance burden > and increases the interpreter bloat; > > - and increases the risk of bugs; > > - somebody has to write, debug, document and maintain the code, > and developer time and effort is in short supply; > > - or the optimization requires changes to the way Python operates; > > - even if we wanted to make that change, it will break backwards > compatibility; > > - and often what people imagine is a simple optimization (because > they haven't tried it) isn't simple at all; > > - or simply doesn't work; > > - and most importantly, just saying "Make it go faster!" doesn't work, > we actually need to care about the details of *how* to make it faster.
Or it reduces memory usage, improves performance, and makes things easier on the programmer... but might place unexpected (or unwanted) demands on other implementations of Python. CPython, by virtue of being the "default" Python interpreter, has to be careful of appearing to mandate something. That's why buy-in from other Python implementation teams (I believe Jython was the most notable here) was important in the discussion about the recent compact dict update. Even what looks like a no-brainer still can have unwanted consequences. > (We tried painting Go Faster stripes on the server, and it didn't work.) Steven Middlename D'Aprano! You should know better than that. "It didn't work" is not good enough. What actually happened? Did the stripes smoulder and smoke until you powered down the server? Did the server raise NotImplementedError when you touched it with the paintbrush? Did your boss walk up behind you and hand you a pink slip? Be specific! > There have been at least two (maybe three) attempts to remove the GIL > from CPython. They've all turned out to increase complexity by a huge > amount, and not actually provide the hoped-for speed increase. Under many > common scenarios, the GIL-less CPython actually ran *slower*. > > (I say "hoped for", but it was more wishful thinking than a rational > expectation that removing the GIL would speed things up. I don't believe > any of the core developers were surprised that removing the GIL didn't > increase speeds much, if at all, and sometimes slowed things down. The > believe that the GIL slows Python down is mostly due to a really > simplistic understanding of how threading works.) Removing the GIL from CPython is not about "speeding up" the language or the interpreter, but about improving parallelism. And I think all the core devs understand this (hence the lack of surprise there), but people who call for it often don't. > (If it weren't for the EU government funding it, PyPy would probably be > languishing in oblivion. Everyone wants a faster Python so long as they > don't have to pay for it, or do the work.) Hm, I didn't know the EU was funding PyPy. Okay. Cool. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
