Dynamic languages are not productivewave-line
There's only one sense in which dynamic languages allow the programmer to produce more in less time: short throw-away scripts for personal use.
For everything else, there's no productivity gain at all.
The lack of compile time type checking makes code harder to read, harder to develop, harder to maintain, and almost impossible to refactor.
What invariably ends up happening in dynamic code bases is something like this: the code is split into many classes with many methods, or just many functions. Each function takes several parameters, usually having short names. Many functions just pass and receive parameters to and from other functions. The function that eventually does the actual work is usually several levels down the call stack. By the time you do find it, you've lost track of what the inputs and outputs are. You can sort of imagine what the function is trying to do, but you're never really sure, and if the function is more than 15 lines of code, you'd be scared to change it.
A parameter might be named "customer", but do you know what kind of object is it? Is it a row from a database query? Is it an instance of a class from the ORM layer? Is it a json representation of a user request? Is it a json representation of a response object that is in the middle of being built? Is it just the name of the customer that is going to be passed to some other function that will then fetch it from the database? Is it the customer id? If so, is it a string or a number? It could be a number but the type is string because the value came from several functions up the call stack where the source was a user supplied parameter that was passed as-is (as a string) without ever being converted to a number anywhere in between.
You never know! It could be any of the above, or something completely different!
You have no idea what the inputs are and what the outputs are.
What happens when you need to make a change to some existing functionality?
This mode of developing is not productive at all.
Python code might be initially fun to write, but it's hard to read, and a nightmare to maintain.
If you are using python, you are almost definitely better off updating to 3.6 and utilizing type annotations to the max. Although python's type annotations are much weaker and more difficult to enforce, specially when using libraries with a lot of meta-programming sorcery like SqlAlchemy.
Another problem though is that python (and even typescript) will still forgive you for writing code without type checks, or even code that violates the type checker.
So you are better off just using a language that has a proper compiler. A compiler will never forgive type errors, because it has to produce an executable from your code, and it can't do that if the code is not correct. Which leads me to the next pitfall of dynamic languages.
You can write code in your local development environment, but if you are using any libraries then you cannot really produce a deliverable artifact that you can ship as the final product.
There's no formal compilation step.
If you want to deliver your product somewhere, you have to somehow figure out how to copy your source code there along with all the dependencies. Most people end up having a "requirements.txt" file that declares the dependencies and then run a script to download the dependencies from a central repository somewhere.
If you are deploying a web application server, this usually happens on a remote linux machine.
If you don't declare your dependencies correctly, the code that works on your machine could fail on the target machine.
If one of your dependencies is in a private repo, you have to configure both your machine and your deployment server to be able to read from the private repo.
If on the other hand you were using a compiler, then it can take your source code and produce a statically linked binary executable, so you don't have to worry about any of the above problems.
Performance matters, despite what many people think or claim. Dynamic languages tend to be anywhere from 3 to 10 times slower than native code, and sometimes even much worse. They cannot utilize multiple CPU cores because they only run one thread by design! They also tend to eat up a lot of memory. This means there's a whole range of potential code optimizations that are simply not feasible because it will complicate the code, use too much memory, and still not be fast enough.
If you use python to power the server side of a web application, you are shooting yourself in the foot. If your application becomes successful at all, you will spend long stretches of time "firefighting" all the performance problems that will inevitably keep cropping up.
Even if you managed to optimize a slow portion of your code to be ten times faster than before, then all you've really done is expend a lot of time and energy to produce the same performance that you could've gotten for free from the dumb code in a native language.
All the time you spend firefighting is time that could have been spent to create new functionality instead.