DEV Community

Discussion on: Why all this hate about Python?

Collapse
 
kenseehart profile image
kenseehart

Python is certainly my favorite language for pretty much every project, large or small. I've been using it very effectively as my primary language for over 20 years.

However, I find that I agree with much of the criticisms of python.

The two main weaknesses of python are:

  1. It's very easy to learn
  2. It's very flexible and does not impose it's will on you

This is a horrible combination.

The problem is that people can quickly become quite productive with python before gaining an understanding of the essence of the language, and before learning what does and doesn't work.

For a project to be a success it is extremely important to have expert python engineers on the team, and make sure there is a policy of code review on all commits. Code review is the most important, because most bad habits in python would be spotted by an extra pair of eyes.

Experience in other languages doesn't necessarily help. Python is unique. Many of the most common pitfalls in python are indeed considered best practice in other languages.

A couple examples of this:

Java makes a clear distinction between data attributes and methods. If you think you need encapsulation, you must hide data attributes and use getters and setters to manipulate them indirectly. Otherwise when you change the implementation, you will have a huge refactoring task in front of you.

In python, there is absolutely no reason whatsoever to preemptively wrap your data attributes in getters and setters. You just use the attributes. Change them to properties later if it becomes necessary. Python's flexibility allows you to do this seamlessly without any refactoring outside the class being modified. In python, your best bet is to keeps things simple and concise.

In one project I found over 3000 lines of code specifically dedicated to completely unnecessary encapsulation of ordinary attributes. There was no benefit, and it made the resulting code brittle and slow.

In C++ any medium to large project has a build as a centerpiece. The model is that you have source code which you process to create something that you run. In python you basically just run the source code. Sure it's compiled to bytecode, but that's a hidden caching operation that you usually don't need to think about. And yes, in many cases you have some kind of deployment, but it need not be complicated, that shouldn't significantly impact how you think about the architecture.

So there was this project involving a million or so lines of code. The architecture involved an ad hoc package manager that would concatenate a bunch of python modules into various larger files, encrypt the result, and then use a messy import hook implementation that would load these monstrosities. The order in which things got imported was critical because lots of code would execute on import. When it came time to upgrade to python3, a nightmare was at hand.

On the other hand, I've seen plenty of beauty in python projects. The most successful always involved keeping code quality as a high priority, ubiquitous unit testing, and a high level of collaboration including code review.