Last time I saw the Bank of America python codebase, it had ~6 million lines of code, was worked on by about 4,000 developers, and ran some core, performance critical functionality.
Python programming is an aesthetic that needs learning. Many of the worst written, and least maintainable python codebases I've seen are by programmers/teams coming from "proper" languages and don't think they have to learn how to write idiomatic python.
"So, the sad thing is that these poor folks worked much, much harder than they needed to, in order to produce much more code than they needed to write, that then performs much more slowly than the equivalent idiomatic Python would."
I included a link to this blog-post in the "letter of intent" (don't know the exact English term) that I sent to my potential employer just before my first interview for a professional (Python) programmer job, back in 2005. I got the job. Good times.
And it appears to be a recruiter goldmine, the staff turnover is significantly high (so I am told).
A codebase of this size with no static type checking is not going to be fun.
Bzzzt - not really. Quartz in BoA, and Athena in JP Morgan (both built by the same folks) essentially takes Python, connects it to a bucketload of C++ and Java that makes up the bulk of the banks services, adds on a GUI layer, a pretty crappy object storage layer (shudders at Hydra...) and a half-baked object persistence layer that was always so slow. Sure, a lot of Python scripts get written for those platforms, but the heavy lifting -- pricing, trading, order books, risk systems, market data, connectivity all ends up being C++/Java, maybe in a Python overcoat.
Python programming is an aesthetic that needs learning. Many of the worst written, and least maintainable python codebases I've seen are by programmers/teams coming from "proper" languages and don't think they have to learn how to write idiomatic python.