We Need Python
The adventure with Google Protocol Buffers continues!
The blog post about GRPC was surprisingly popular — I am not really sure why, considering how surface-level it was. Meanwhile, the similarly-named blog post about HTML was completely dismantled, roasted, and peed on by Jason Knight…but not for the reasons I expected. What I thought the post might be criticized for was that it focused solely on HTML, making it a potential target for people who constantly write that HTML is not a real programming language (and it is not). Instead, it was dismantled by someone who has spent 40 years using HTML, someone who argues that the people who create frontend frameworks need to better understand HTML. I did not know you could spend 40 years specializing in HTML.
I thought the comment was pretty harsh and unnecessary, but then I read some of Knight’s other articles and saw that he has replicated pages from popular frontend frameworks using minimal time and straight HTML/CSS. That takes talent. He has my respect for that.
Anyway, I might have to give the HTML blog post a second pass to try to redeem myself, but in the meantime I have this. This is going to be a blog post specifically about Python, and I suppose I am about to find out whether or not Python has a Jason Knight equivalent scouting Medium in search of garbage articles.
Let’s Cut To The Chase
I noticed a lot of tutorials would “firehose” Python, but I thought I would take a different approach here — mainly because this is NOT a tutorial, this is me learning Python and sharing my thoughts. If you would like a post like the one I just mentioned, this is a good one by Educative.
Whenever I see posts with titles like “learn Python in 15 minutes,” I assume they are meant to be primers: You watch or read them, THEN it is implied that you will go out and actually do something to quickly apply your knowledge. For example, the Educative one is a 9-minute read that manages to cover hello world, lists, strings, branches, and functions.
Real scenario #1: You are using GRPC. Data point of one, but for whatever reason you had an easier time getting the Python working than you did any other language on your machine.
Real scenario #2: You listed Python on your resume, even though you don’t know it, and you have a coding interview tomorrow. Obviously this is hypothetical — if you were actually caught making a lie like this, they would haul your ass off to prison.
Above, we have FizzBuzz. That’s nice. So hopefully if anyone is hiring for Python developer, you need only pass FizzBuzz and you will be on your merry way.
Anagrams is a little bit more interesting. You can find it on LeetCode here, and it’s a good entry point into coding interviews. You want to determine if two strings are anagrams — you can use a hashmap, but you can also use an array that acts as a kind of hashmap. Your key is the letter. Your index is the count. Increment for the first string, decrement for the second string, see if you have all 0s…you can solve the problem in linear time, which is the kind of efficiency they love in these kinds of problems.
Some points:
- Comments can be made using #. You can also make multi-line comments
- A string can be defined in single quotes or double quotes
- The so-called hashmap above is actually a Python dictionary
Some More Interesting Tangents
Why is Python so popular? This article argues that it is because of the community behind it, while people in the comments point out his claim that the language is “slow” is kind of misleading. It is supposed to be really intuitive, but I lack the knowledge to be allowed to have an opinion on that.
Are interpreted languages better?
The short answer is “no,” but it makes for a pretty compelling FreeCodeCamp article.
Python is not compiled, it is interpreted (see paragraph below). This is in contrast to a programming language like C++. There is a real-world advantage to this that I have experience with, but I will not name it here…if I do, someone will drive to my house and slap me.
[*Edit 6–19–2022: As a comment pointed out, the paragraph above is not true and there was no simple way to remedy the error. Python IS compiled, it just might LOOK like it isn’t to a developer who is used to using another programming language to explicitly compile, then run in a separate step. For more information, read the comment below or this StackOverflow post
https://stackoverflow.com/questions/6889747/is-python-interpreted-or-compiled-or-both]
According to the FreeCodeCamp article, this makes the Python code itself platform independent.
In short, there is a trade-off between compiled languages and interpreted languages. Compiled languages tend to be faster.
How the heck is this strongly-typed?
…is a question I asked.
Well, as StackOverflow points out…
Python is both strongly typed and dynamically typed. According to this article:
Strongly typed is a concept used to refer to a programming language that enforces strict restrictions on intermixing of values with differing data types. When such restrictions are violated and error (exception) occurs.
So the fact that Python is dynamically typed does not make it weakly-typed. I admit that I used to think it was weakly typed because…well…look at the way variables are defined. There is no explicit keyword to designate that a variable is a string, a character, or an int.
What’s the deal with relative imports?
I still don’t really understand this. It’s a discussion that took place on StackOverflow here.
It definitely came up for me before, and we will see if it comes up again. The only reason I was able to work through it in GRPC is that I realized GRPC was smart enough to include some imports in its auto-generated code, and these were all correct and usable.
The Adventure Continues
I proceeded with defining corgi.proto, which is completely and utterly unnecessary but I am sticking with it.
It’s pointless, but I would argue that “hello world” is as well…depending on how you define the word “pointless.” I intend to invent my own stack. It will be called the EVAN stack, and will consist of Express.js, Vue.js, A GRPC server, and Node.js.
Um, and maybe a database. If there’s time.
Closing Thoughts
I am not sure where we will go from here. GRPC is ready for exploration, but so is a lot of the frontend stuff.
The idea with GRPC/proto is that you can send just about anything. Yeah, we can send a corgi with a request/reply…what would the point of that be? Maybe bidirectional streaming corgis. What kind of madman would represent a corgi using text? I think it makes about as much sense as the rectangle example Google provides, but a more practical service might be worth exploring.
Then it would be interesting to see how this compares to a more traditional RESTful API, but baby steps.
So why Python for the GRPC work? Well, because.
