Not only is Python not dying, but it's stronger than it's ever been. The majority of top colleges are now teaching CS using Python. It's completely dominant in academia, finance, and startups. It has the best libraries and documentation of any language. And Django has arguably the strongest community of any open source project period.
That's not to say there are zero problems, but Python is so much better than all the other alternatives that this just seems like a ridiculous question.
I wouldn't say Python is dominant in startups across the board. Though it is strong in data-heavy environments (with all it's issues nonetheless).
I've been a Pythonista for over a decade, and the API scene isn't quite as utopian as you describe. Date/time handling in particular is a really poorly handled area, but there's quite a few out there.
That said, in general I agree the 'batteries included' approach is good, and the libraries _tend_ to be easy to use for most tasks. Compared to most Java libraries, it's a breath of fresh air.
I think there's more of an interest in scalability and compile-time checking among startups nowadays, hence the shift from dynamic languages to lightly static languages like Go or all of the type-checking and Haskell-derived JS variants out there.
This means Python and Ruby aren't as much of a first choice as they used to be, even if they're arguably a lot faster for getting MVPs out.
> I think there's more of an interest in scalability and compile-time checking among startups nowadays
Which is precisely why all of my new code targets Python 3 and I use PEP 484, and before that I always had type information in my docstrings. There's some places where duck-typing makes sense, but a lot of times I'm really just doing things like I would in a statically typed language so I just type the crap out of everything and run MyPy against it.
Unfortunately the runtime itself doesn't benefit at all from the type information, but I know I any of my .Net-centric colleagues can easily inherit any of the Python code I've written and be able to read it without much headache - without having to intuit what magic goes on behind the scenes, especially with things like the Pyramid request/context objects.
I'm not sure if that's the best way to describe them. IMO, NumPy/SciPy are probably best described as Python wrappers for a wide range of C and Fortran codes, but they add quite a lot of value on top of that. If you've ever used e.g. LAPACK or VODE directly, you'll probably have horrible memories that you prefer not to recall. NumPy and SciPy have a large contribution in that they unify (admittedly, neither is really a paragon of consistency, but...) a huge range of disparate libraries under a much more accessible interface.
To say NumPy or SciPy is just the sum of the libraries it uses is a bit like calling MATLAB a fancy interface for LAPACK. That really was what MATLAB was intended to be originally, but to reduce it to that is missing the appeal. As somebody who absolutely loathes MATLAB, even I wouldn't think that is fair.
The major feature of Python for me is that all its various open source modules for anything n-dimensional (matrices, image processing, GIS, machine learning, etc etc) all use the same data structure: the Numpy array. It's basically part of the standard library that is developed outside of it for pragmatic reasons. And with the speed of Fortran array operations.
That's something that only Matlab really has as well, but Python is much better in other aspects.
> Not only is Python not dying, but it's stronger than it's ever been.
Yeah, I've followed Python since about 2000. For the next 5yrs there was steady growth as it displaced Perl. But it was looking quite shaky/vulnerable around 7-10yrs ago when Rails was growing fast with lots of hype.
Around that time publishers almost stopped writing any Python books at all. Look at it now though - Python is probably in the top three most popular languages for programming books at the moment. I've never noticed so much Python stuff around before.
Now that I'm moving to a more Ruby focussed devops job, I've had a look around for new modern Ruby books and I've noticed they've almost dried up completely.
Actually that's probably not accurate now that I think about it. Python is mostly used by quants and people figuring out what trades to make, as well as for some of the internal business tools. Whereas the people building the actual exchanges are probably using Java or C++.
"Finance" is such a broad term with respect to IT - you'll find anything if you look hard enough. The following is based on my experience only - I'm sure there will be lots on here with different experiences:
* I've seen more C++/Java/C# than anything else, with a large legacy base of COBOL/RPG (yes, GMI, we're looking at you...).
* Industrial-grade quant libs (for risk, P&L, models that need regulatory approval) tend to be in C++, with the infrastructure to run them increasingly in Java.
* Lots of VBA on the desktop. Every department runs on Excel...
* Python is making inroads (see Quartz at BofA, Athena at JPM), but I suspect that it's still vastly outnumbered (by whatever measure) by C++/Java.
Some firms (and departments in bigger shops) embrace new technology agressively - at my firm I know of large Scala projects, python, big data (mainly Mongo/Hadoop), R and some Haskell.
That said, on my first job in the UK for a large insurance firm, we employed a team that wrote custom CICS machine code for Z-series mainframes. Beat that with yer fancy functional languages...
I hear BofA are back pedalling on Quartz. Kirat has left, and there's some new senior IT mgmt who don't want to put all their eggs in one basket. Just gossip, would be interested in any confirmation/refutation...
That's not to say there are zero problems, but Python is so much better than all the other alternatives that this just seems like a ridiculous question.