> The vast ecosystem of python libraries is an incredibly powerful argument for using it.
vast ecosystems exist in other languages as well. python is not magically the only language that has libraries. in my experience, python libraries exist but aren't great and lead to issues. also in my experience, .net libraries often exist alongside the python libraries, and in many cases companies often provide C/C++ DLLs or .NET assemblies more often than Python APIs.
> One major library could dramatically cut the development time of your project.
in my experience, the half-baked nature of python libraries actually increased development time.
> You’ve not spelt out actual reasons why Python is so bad, could you give your top three?
thanks for asking this rather than indiscriminately downvoting. my reasons are:
* the module system is a mess and can hardly be called a system. anything greater than a few scripts and modules becomes a mess, whereas other languages have much better module and project systems (the latter of which python doesn't even have). the module system in python is little more than a hack just barely exceeding file path linking.
* pip is a mess.
* the python 2 vs 3 issue is trivialized by people, but it is anything but trivial in practice. the first python codebase i worked against was using an internal tool at a large company. they were actually using python 2.6, and it was me, a new user, who pushed them to use 2.7 (which didn't happen before i left). the next system i worked on was also using 2.6 at another company, and i upgraded them to 2.7. the installation procedure for the python packages was a mess (see the module system and pip being a mess). upgrading them to python 3 was a non-starter and on further projects, they ignored my suggestions to them (i wasn't working on the system) to upgrade to python 3 because they didn't see the reason to. next system was also in python 2.7, and due to package obsolescence and deprecation and version jumps, the entire codebase basically required being rewritten in python 3 and newer packages.
* the ecosystem isn't as complete or robust as people imply. even python's built-in XML parsing library has many issues and lack of features, and i have even seen differing behavior between linux and windows.
* python the language is most simply described as unprincipled. there are surprises and gotchas everywhere. for example, the following generates a run-time error:
def now():
return "now"
def usage():
now = now()
return now + "!"
the error is "UnboundLocalError: local variable 'now' referenced before assignment". now do the same in f# or racket or any other sane language in which expressions return values which are then bound sanely to identifiers. python is full of stuff like this. if you've used more sanely defined languages, coming to python is actually quite complicated because it is so unprincipled. it does not have a small core base layer that allows for predictable code.
* python has no consistent way to write asynchronous or concurrent code and has major limitations on whether the code you write is actually concurrent. i've done a lot of concurrent code. when i learned elixir/erlang, it was so easy to understand (many python people probably consider elixir/erlang to be more complicated than python), but when i tried to learn asyncio in python, it felt very complicated. there are tons of caveats right off the bat, and it is completely different than other ways of writing concurrent programs in python.