I feel like there is sometimes a thirst on people's part for change for its own sake, and that's really not great when it comes to computer languages. I think the relative stability of the core syntax of python is not a bad thing.
Yeah, mine is not a criticism to Python per se, I definitely value this thing. I'm just saying that I'm not sure it fits in my brain as easily as it did when I picked it up first.
For example, I think the import/module/package system in python has continued to be confusing from day one, and it's not really much better today than it was in python 2.
I partly agree. The package system has been messy but the import and module system is quite alright. BTW I believe Pipenv covers almost every need now
I think npm is far superior for example compared to the mess we have in python.
Maybe, but in reality npm suffers by the enourmous amount of small packages with large dependencies trees that transform node_modules in a mess. The tool is solid though. "Far superior" to me means that the other tool is barely ok, but I wouldn't call Pipenv barely ok. It works.
It took too long to get there and there are still kinks but I believe we're on the right path. Finally 😅
Another thing is the infamous global interpreter lock. It's not something that is always going to be a major problem, and there are of course workarounds. And some people will even argue that it has some benefits. However I do consider it to be fundamentally inelegant and kind of weird for a modern programming language.
I disagree. The GIL was a very smart move (Python was developed at the end of the 80s, not exactly a new language), it made the Python ecosystem of libraries and packages develop faster with the added bonus of creating (mostly) thread safe extensions. Many industries ate it up because they could use its simple syntax and extend with C wrappers. I think the GIL is one of the reasons why Python popularity grew over the years and it still relevant after 30 years.
Someone thought about removing it in Python 3 (they were already breaking compatibility) but they didn't because they still didn't think it was worth it: extensions would become harder to write and single threaded Python programs without the GIL would be slower.
Keep in mind that the GIL is a real limit only with CPU bound multithread programs that do calculations in Python. If you are I/O bound you're fine. If you're CPU bound but inside the C API you're fine.
This is one of the reasons the GIL is still, with its drawbacks, a smart move for Python.
ps. there are implementations of Python that do not have the GIL like Jython...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Yeah, mine is not a criticism to Python per se, I definitely value this thing. I'm just saying that I'm not sure it fits in my brain as easily as it did when I picked it up first.
I partly agree. The package system has been messy but the import and module system is quite alright. BTW I believe Pipenv covers almost every need now
Maybe, but in reality npm suffers by the enourmous amount of small packages with large dependencies trees that transform
node_modulesin a mess. The tool is solid though. "Far superior" to me means that the other tool is barely ok, but I wouldn't call Pipenv barely ok. It works.It took too long to get there and there are still kinks but I believe we're on the right path. Finally 😅
I disagree. The GIL was a very smart move (Python was developed at the end of the 80s, not exactly a new language), it made the Python ecosystem of libraries and packages develop faster with the added bonus of creating (mostly) thread safe extensions. Many industries ate it up because they could use its simple syntax and extend with C wrappers. I think the GIL is one of the reasons why Python popularity grew over the years and it still relevant after 30 years.
Someone thought about removing it in Python 3 (they were already breaking compatibility) but they didn't because they still didn't think it was worth it: extensions would become harder to write and single threaded Python programs without the GIL would be slower.
Keep in mind that the GIL is a real limit only with CPU bound multithread programs that do calculations in Python. If you are I/O bound you're fine. If you're CPU bound but inside the C API you're fine.
This is one of the reasons the GIL is still, with its drawbacks, a smart move for Python.
ps. there are implementations of Python that do not have the GIL like Jython...