I’ve been learning some Python this past month. My initial thoughts are as follows:
- The language itself is fine I guess. Close enough to Ruby to make me happy. I still don’t like the significant whitespace, but I found a formatting tool that aligns my code according to the official style guide, so I only ever have to add the bare minimum indentation, and let the tool take care of the rest. It’s the closest I can get to avoiding it.
- I don’t know if it is the language or me, but I am shocked at just how many times I’ve written some code that works on the first try.
- I’m not entirely sold on the idea that Python always has just one way to do anything. It might be true in general, but I’ve already seen a few instances (mostly related to string processing) in which there alternative strategies, some of which are cleaner and faster than the most common or obvious approach.
My complaint here is not that the original claim is false. I’m quite used to having to figure out the “best” way to do something. No, the claim does concerns me because it lulls inexperienced programmers into a false sense of security. Once they’ve figured out how to do something, they might assume that it’s the only way, and never bother to look into whether there was an alternative. Why explore the depths a language if you’re being told not to worry? - Coming from years of Java development, I don’t have much nice to say about Python’s development tools. It is incredibly confusing to learn them, because there have been many different tools created over the years for every different task, including packaging up code, running tests, and dependency management. Figuring out which ones are the current state of the art isn’t easy when you can’t tell whether any given tutorial or guide is out of date.
- Furthermore, as a Java dev. I was initially appalled at the way Pythoners handle dependency management. When creating a library of your own to share with others, it is not recommended that you pin your dependencies down to specific versions. In JVM languages, such talk would get you roasted. In Python (and sadly Ruby), there is some strange fear that locking into a version is too dangeorus and restrictive.
I eventually got over this hangup; after all, I know my projects and my needs better than anyone, and if I feel it is best to go against the grain, so be it. But it does highlight the differences in the two communities. Java developers often work in “enterprise” environments, where upgrades are slow and careful and you better know what you’re running in production every single time. As for Python, it seems that many developers use the language because it provides libraries that make their non-application development work easier. They care about installing stuff that works in their scripts, not about creating reusable libraries. That means they don’t care too much about version numbers, as long as everything still works. For them, my concerns are a non-issue. - Initially I wasn’t a fan of ‘virtualenv’, but once I got in the habit of activating it every time I sit to code I began to dig it. I like how it removes concerns about permissions when installing libraries, and I often create environments that have particular command line tools that I like to use to generate things like documentation or charts. That being said, I still prefer Ruby’s solution to project isolation, which boils down to “Run Bundler in front of every single one of your commands and you’ll be fine”.
- There is a lack of consistency within Python itself that I’m still trying to get over. The style guide suggests using underscore-based naming conventions for things like variables, methods, and even module names. But within the standard library itself I’ve seen functions which use Lower Camel Case, or all lower case characters with no underscores. This is likely due to the age of the language, as many new things have been added to Python over the years. But it makes it harder to learn the standard library when you have to remember not just the function name but its formatting.
- It is very nice to be able to once again work in a language in which I can write a file full of functions without the ceremony of creating and instantiating a class. Sometimes that’s all you really need.
- I’m also glad that I can still write classes when I need to.
- In Ruby, when you install a Gem, the default is to also install any corresponding documentation that comes with it. This is supremely handy in situations where you aren’t online, but still need to consult the documentation on an API you’re trying to use. I assumed that Python did the same thing, but alas it is not to be. There are no official rules for generating Python docs, and in fact there isn’t even a single tool that everyone agrees upon. For a newbie, it’s kind of a mess.
So what does any of this mean? What can deduce about Python and its community? My answer is going to sound like a cop out, but it tells me that Python is like all other popular languages, in the sense that the language and the ecosystem around it is shaped by the needs of its community. As I alluded to earlier, the same can be said for Java. The Java ecosystem was very clearly built by people writing Enterprise software, because so much of the libraries and tooling surrounding the JVM are written with “Enterprisey” priorities in mind.
Python, on the other hand, appears to be driven by two groups of people. First, by folks who looked at it mainly as a scripting language, and more recently by folks using it in the fields of mathematics and Data Science. I do not mean to disparage these folks in the slightest (they are capable of doing things I could only watch and admire), but when you can do the majority of your work by firing up Anaconda or Jupyter, and can create magic using nothing but numpy and pandas, you don’t need to worry much, if at all, about the same things that “traditional” software developers do. The concerns of the Python community at large and the Java community at large don’t seem to have a ton of overlap.
Again, this isn’t a bad thing. It just reminds me that, as always, different tools (and programming languages) are a better fit for different kinds of work. There are a lot of problems I’m more comfortable solving in Java, but I can already see a number of situations in which I’d be crazy not to go for Python.