4 ms·
Python is just plain unsuitable for any project larger than a couple of files. Every Python project contains a hidden and deadly complexity that will grow over
by plasticeagle 2y ago
Python is just plain unsuitable for any project larger than a couple of files.
Every Python project contains a hidden and deadly complexity that will grow over time - and will eventually destroy it. There's no way around it, it creeps in no matter what you do. The imports situation is only part of it - it wasn't what killed our simulation tools, or our build scripts, or our test framework - and required that we rewrite them all in different and more suitable languages.
Python's performance, global modules, whitespace, untyped-by-default code are all killers. You pretty much have to use virtual environments to permit isolation between the multiple differently-versioned sets of dependent packages that you'll need for any project of any complexity, which are a cumbersome and painful solution to a problem that simply shouldn't exist.
It may technically be possible to write clean and maintainable code in Python if you try hard enough, but you're always skating so close to the edge that eventually somebody is going to get in there tip the whole fragile mess into the abyss.
- nick238 2y agoWhat's the one true language we should all be using?
- valiant55 2y agoI don't think such a thing exists or should exist. Languages should be different and those differences will naturally be better at a variety of problems. But also it's definitely C#.
- Daishiman 2y agoLooks like somebody isn't running a linter on CI.
- sevensor 2y agoI’ve led the maintenance and development of a medium sized (100s of kloc) Python codebase over a period of five years. As it matured, the code became significantly less fragile and more maintainable. Using private members of modules (or any other object) turned into way less of a problem as we improved our design. Turns out the problems were mostly around I/O and mutable state. We fixed those problems by pushing side effects and mutation as far out to the edge of the codebase as possible. If your core data processing routines don’t have side effects and don’t mutate global state, who cares who the caller is?