3 ms·
> My grip is actually the contrary, many python code bases are stuck in the past. From the outside looking in the Python community seems aggressively anti rewo
by dlisboa 5y ago
> My grip is actually the contrary, many python code bases are stuck in the past.
From the outside looking in the Python community seems aggressively anti reworking their code to adapt to new language features. The 2 to 3 debacle comes to mind when compared to other languages, like JS, which made a much bigger change and everyone jumped in it and rewrote their code to adapt, or Ruby which went through some backwards incompatible changes at the same time as Python.
- scoopertrooper 5y agoI don't think there has been a non-backwards compatible JS change in a very long time. They even named the array flatten method as 'flat', just to avoid having a conflict with MooTools!
- dlisboa 5y agoMy point with JS is more that the JS community sees no problem and will actively rewrite vast swaths of code to use features that are not yet supported in browsers. Hence the extensive use of polyfills and transpilers. Major language changes are generally seen as a good thing (which they mostly are in JS' case). With Python I don't get the same feeling, they seem more resistant to change in general. I don't think it's just that Python has more so-called "non-programmers" (meaning, data science and math people). Most of the libraries for these things are made by full-time programmers anyway. Perhaps the idea that "there's only one way to do it" brought about a "the current way is good enough, why rewrite in a new one?" attitude. But anyway, I'm not familiar enough, just an outside perspective.