3 ms·
> The fact that such a talk exists shows that the improvements aren't worth the switch for most users. If they were, they wouldn't need convincing. That's read
by EdwardDiego 4y ago
> The fact that such a talk exists shows that the improvements aren't worth the switch for most users. If they were, they wouldn't need convincing.
That's reading far too much into a tongue in cheek presentation title.
Besides, good devs are typically reasonably skeptical of new and shiny.
And when you've got a large Python 2.7 codebase, and Python 3 is backwards incompatible, you'd be looking at a lot of work to upgrade, so damn straight you'd need convincing to make the investment.
Hell, look at how many Java codebases are still 1.8 because of the upgrade cost of going past that, even though modern Java has many compelling features.
And expecting Python 3 to remove the GIL is incredibly unrealistic. How much Python code in the wild implicitly depends on the behaviour of the GIL? All of it.
- mike_hock 4y ago> How much Python code in the wild implicitly depends on the behaviour of the GIL? About as much as depended on Python 2-specific features?
- EdwardDiego 4y agoSure, but the GIL behaviour is inherent to all concurrent (for a given value of concurrent) Python code. And code that could be run concurrently. Removing the GIL would be bloody fantastic, but it's far more involved than 2 to 3.
- seba_dos1 4y agoA lot of codebases could be converted from Python 2 to Python 3 with just some fairly mechanical work and light refactoring on top. GIL would be a thing of a completely different magnitude.
- debugnik 4y agoOCaml 5 recently solved the global lock problem by introducing concurrent domains in which one or more threads share a lock. So old code keeps spawning threads with a shared lock, but new code can work with single-thread domains and manage in which domains does old code run.