| I got into Python from C/C++ for data plumbing in the late 2000s, before data science / ML really took off. I think much of what appeals to me comes in three camps: One: "Zen of Python" philosophy. The idea of both explicitness and being "exactly one way of doing things" helps with menial tasks I don't want to think too deeply about. Maybe I _shouldnt_ think too deeply about how I move some files around, parse JSON, or hit an API. Two: Batteries included. The standard library has always been extensive and "just works" in ways other language ecosystems have long struggled to catch up to. Especially for data / file plumbing tasks. It's also not very complicated to do most simple things in without a 3rd party library. Three: C integration. Writing native C modules seems to have been baked into the language from day one which has led IMO to much of the data science ecosystem. The ecosystem seemed to connect with the practical, old-school C programmer part of my brain, and make a lot of sense from a perspective of "get shit done" imperative programming style. One maybe critique - I think the nature of Python, and how people historically approached it, can lend to a kind of lazy/bad software engineering. People historically had gotten into Python because of dumb scripts, and not because they care to think deeply about how code SHOULD be structured. Python's practicality is a bit in contrast with the culture of Ruby where aesthetics are highly prized. So a criticism of Python could be its very easy to get started with a dumb script, to solve a practical problem, that eventually becomes a critically important project. Unfortunately everyone just focusing on "getting the next thing done" means it can morph into unmaintainable spaghetti mess because its some side thing. I don't know if that's the languages fault per-se, or just a side effect of the "lack of ceremony" needed to do work. Certainly, you can and should have high software engineering standards for your Python project. Just something I've observed perhaps as Python itself can often be a "side" thing, not the primary focus of practitioners. |