3 ms·
I disagree. Most people working on GIL in Python this days are definitely smart, but they're brute forcing the problem. It's not about writing more code, for m
by mdomans 10y ago
I disagree. Most people working on GIL in Python this days are definitely smart, but they're brute forcing the problem.
It's not about writing more code, for me, but about writing smarter code. GCD was, for me, an example of such feat. It introduced an approach that obsoleted thread as a concept you work with
- jerf 10y ago"Most people working on GIL in Python this days are definitely smart, but they're brute forcing the problem." I have no idea how to translate that into the real actions I'm seeing. What is "brute forcing the GIL"? If you mean "solving the problem in the runtime instead of writing 'better' code", well, per my previous post there are times the "better code" can't be written in Python anyhow, but putting that aside, there's all sorts of reasons to fix things in runtimes rather than require people to "write better code". First of all, you get massive leverage fixing things in runtimes because the improvements directly apply to the staggeringly, incomprehensibly enormous pile of already existing code in the field. Secondly, the "just write better code, everybody" has a multi-decade track record of multidimensional failure in every metric, from code quality, security, performance, reliability, everything. What can work is making correct code easier to write, which doing things like fixing the GIL can for the certain cases where that's a problem; telling everybody to do the harder-but-correct thing does not work at any scale much beyond 1-developer code.