Subjective Python or why I “hate” Python

Different people look at different facts and also interpret them differently. Following are my chosen facts about Python programming language and my subjective opinion about these facts, the Python language, and its use for DevOps.

Background

As I do from time to time, I post comparisons between Next Generation Shell (NGS), a shell I’m working on, and other languages, Python included. The comparisons are typically involving some small task that I consider a “typical DevOps task” (defined later). As you can imagine, in these comparisons NGS always wins. First, because NGS was specifically designed for and is actually better for many DevOps tasks. Second, because there is no reason for me to post a comparison where NGS is not better. Anyhow…

After such post on LinkedIn (“Still using #Python for #DevOps? You like to suffer?”), where I compared sample NGS and Python code, a friend asked me why I “hate” Python. My answer was that I’m feeling neutral about Python.

I found the topic of my perception of Python interesting and deserving elaboration.

Python

From my perspective, Python is okayish language, relative to other programming languages.

While I understand people that are annoyed by Python 2 to Python 3 migration and breakage, I also realize that it’s very hard to get things right from the start (or even later).

Few things in Python from the top of my head that are annoying for me:

  • Python does not encourage nor supports well basic functional programming: map() and filter(). Due to Python’s syntax, the callback lambda can only be single expression.
  • Instead, it encourages list comprehensions which act as both map() and filter(). I don’t like list comprehensions, they don’t align with how I think. Dict comprehensions too.
  • Typing is afterthought and therefore “The Python runtime does not enforce function and variable type annotations. They can be used by third party tools such as type checkers, IDEs, linters, etc.”
  • Conditional expressions (A if C else B, where C is the condition) are breaking my head.
  • if __name__ == "__main__" hack idiom is ugly as fuck.

There are annoying things in any language though.

My strongest negative feeling about Python, for which I should mostly blame myself, is parameters handling. While working on NGS, early on, I copied was inspired by parameters handling in Python. The thought was that parameter handling is such a basic thing that (A) I shouldn’t spend much time on it and (B) such established language like Python would get it right. Python didn’t get it right. And I copied that atrocity. They ugly-fixed it later. I’m still thinking how to do it right. The “right” for NGS is likely to differ from the “right” for Python. Also, I would like to avoid making the same mistake for the second time.

What do I actually “hate” about Python?

What I “hate” about Python is surprisingly not Python-specific. It’s the use of square pegs for round holes:

Using Python, Ruby, Go, and other languages that were not intended for “typical DevOps tasks” (looking at resulting code for that judgement) when you have clearly better matching alternatives, including NGS and some other modern shells.

“Typical DevOps tasks” include running external programs and small scale data manipulation (files, structured data, mapping, filtering, pattern matching).

Justifying the Square Pegs

This one is annoying, especially hearing the same arguments for 1000th time.

“But I can do it with libraries”. You can. Also you can do it in Assembler, C or FORTRAN with or without libraries. I do not except the argument. The solutions are not equal.

“It’s not that much of a difference”. Depends on the use case. Run external program in Python and handle exit codes properly and let’s talk then.

More legitimate arguments include:

  • “Our team uses Python and so we do DevOps in Python too”
  • “We are afraid we will not find Stack Overflow answers if we are stuck”
  • “We are afraid we won’t be able to hire developers in this new language”
  • “Where is the tooling?”

In my mind, the legitimacy of the arguments above is in reverse proportion with DevOps work volume. The more “DevOps” tasks you do as percentage of your total work, the more advantages of better suited programming languages shine through.

While sometimes the arguments are justified, other times it’s inertia which is holding us back. Like switching away from JavaScript which is not going according to the plan.

Programming Languages in General

Subpar. All of them. At least the ones that I have seen (dozens). Python included. NGS included. We as humanity didn’t figure that out yet. I mean programming languages. We are stuck in paradigms which hold us back.

NGS aims to be less bad for DevOps than the rest because it was designed for the niche. Almost round peg for round hole, way better than the square pegs.

Conclusion

While it might look like I “hate” Python,

  • it’s actually all programming languages
  • and even more so their inappropriate use and the worst is
  • justifying and perpetuating inappropriate use of programming languages

Thanks for reading, have a nice ${TIME_OF_DAY} !


For the curious ones, code comparison follows.

The Code Comparison

During my quest to understand CloudFormation better, I stumbled upon this code:

"Gets the name of the folder with the handler code"

import json
import sys

def main(rpdk_path):
    "Get the source folder from rpdk config"

    with open(rpdk_path) as f:
        obj = json.load(f)
        entrypoint = obj["entrypoint"]
        print(entrypoint.split(".")[0])

if __name__ == "__main__":
    main(sys.argv[1])

To which I responded with NGS version (renaming mostly meaningless obj to conf on the way):


#!/usr/bin/env ngs

# Gets the name of the folder with the handler code

F main(rpdk_path) {
	conf = read(rpdk_path).decode_json()
	echo(conf.entrypoint.split(".")[0])
}

To which my friend responded with another Python version, which was shorter and did not have main().

Command Line Arguments

Both the original and the shorter version in Python require import sys which shows that dealing with command line arguments is not as “important” in Python as in NGS.

The gap is between additional import in Python and out-of-the-box automatic parsing of command line arguments and passing them to main() in NGS.

JSON

Both Python versions require import json, showing again that it’s easier to deal with JSON in NGS than in Python.

The example would be even shorter if the use case was slightly more typical – the JSON file would have .json extension. read(rpdk_path).decode_json() would become fetch(rpdk_path), leaving Python far behind.


Amazing! You stayed here till the end. Congrats and thanks!

Motivation to Keep Going on a Project

I have a friend that likes the feeling of progress in the professional area. He considers working on a project as part of his professional development. Following our discussion with regards to staying motivated on such a project, I would like to describe the factors that keep me going. Your factors are likely to be different but I would like to share mine as a starting point.

I hope that this article will help you, the reader, to pick and/or stay motivated on your own project. Note that you should first think hard about what you are trying to achieve and whether a project is the right solution to that.

My Project

The project I’m basing my self-observations on is Next Generation Shell, an open source shell which doesn’t ignore advances that happened outside of the terminal for last decades (do you feel the pain in these words?). I started working on the project in 2013. As of time of writing, which is 2024, I’m still on it.

The project has two main parts:

  • Programming language – it’s in a good shape and we use it at work
  • User Interface – early stage, too early to impress anyone

Motivation

I can not separate motivation from picking the project. In my case, all the original motivation behind starting the project is still relevant. It’s worth noting that my feeling is that this project chose me, not the other way around.

Roughly from more significant motivators to less significant ones:

  1. Pain. My project solves my own pain. I was programming in bash and Python. They both suck for DevOps scripting. Looked around for other languages and projects that would be aligned with my vision of the solution. Found none. Decided to do it myself. It was very clear from the beginning though that the amount of effort to solve my own pain doesn’t justify working on the project… if not for the next point:
  2. I like helping others to be more productive. Software is a very scalable way to do exactly that. While you can maybe generalize this as “the project is aligned with my values”, I tend to think about this as “the project is aligned with my intrinsic motivation”. While the programming language should make the user more productive, the UI should really take the productivity to the next level (some would categorize the UI as “groundbreaking”).
  3. The project became usable long time ago. Around 2016 I think. Seeing that it actually works for yourself is a great motivator. From GitHub issues that are opened from time to time, I assume that others are using NGS too. That means that NGS works for others too, at least to some extent.
  4. The project is mentally challenging but not too hard (ignoring speed optimizations here, which could be). When I started, I knew roughly how to do it. It touches two topics that I enjoy: programming language design and semantics.
  5. While I’m writing an NGS script I’m always thinking “how this can be more ergonomic?” and constantly improving the language. When I do the appropriate changes, it’s “NGS just became a bit more useful”. That contributes to the feeling of progress.
  6. While looking at any piece of code in any other language, it’s always a challenge: should NGS do it better? If yes, how? It’s very motivational to see that in many cases NGS does it better that the piece of code in front of me.
  7. Speaking of comparison, it does make me feel good that the niche is still not covered (amazing how bad the things still are) and therefore has huge potential for improvement of productivity. Looking at other projects that showcase anything but working with the cloud I’m thinking “Yep, we still need a shell to work with the cloud”.
  8. It’s something to show to a potential future employer.
  9. Not a near future plan but there is a potential for a startup here which would provide cloud-based enterprise features (I had a list of such features written down somewhere). If you can do that around a terminal, I guess you can do it around a shell.

Demotivation

Some things are demotivating when working on the project. Here they are and how I handle the ones that I know how (after “//”).

  1. “You don’t understand, bash is perfect, we don’t need another shell” comments. // There are people that just can’t be moved easily.
    • I’m sure some assembler programmers didn’t want to move to Fortran or COBOL or C. Some didn’t want to move from these to let’s say Java or Python. There is no more “right” motivation behind creating a programming language than dissatisfaction with existing ones.
    • With regards to UI, some people think that Command Line Interface which mostly limits the interaction to a single line is the pinnacle of UX today. Well, I disagree and I’m about to prove that we can do better. It’s actually partially proven since 1976, when Bill Joy released vi which used the whole screen for text editing. Now I just need to prove the same for the shell instead of text editing.
  2. UI is not ready yet and I can’t show it. I assume it’s way easier to sell productive UI than a programming language. // It shouldn’t be to far away from bare minimum demo though.
  3. Attracting users and developers is hard. I suspect few reasons:
    • It’s harder market now. When you have C and you release awk the amount of convincing is way less than when you have Python and Ruby and many other languages which are popular and kind-of do the job.
    • My personal skills in attracting people to a project are not great I assume // Need to team up with someone but again – need to find that person first
    • I’m prioritizing technical work above finding users. I guess that “solving my own pain” dominates here.
  4. The changes needed to be done to the language to make scripts at work more ergonomic (which I just like doing) come at the expense of working on the UI. It’s just really a hard tradeoff.

What motivates you? What demotivates you and how you handle that? Share in the comments.

Have a nice day!