Python Mysteries for Beginners

Guglielmo Feis
DataDrivenInvestor
Published in
7 min readMar 11, 2020

--

It’s (relatively) easy to get started with Python. There are lots of tutorials, videos, etc. And I guess this post classifies as one of them as well.

Still, after setting up your environment and learn the syntax, there some hurdles and mysterious mechanics of Python that are hard to face as a beginner and that pro coders can’t recognize as such. It seems once you enter a new mindset you can’t go back to when you used to struggle. (There are exception like Norvig’s Infrequently Answered Python questions)

The difficulty in bridging the gap from “I know Syntax” to actually might be compared to knowing grammar and actually speaking or knowing that the Lydian mode has a #4 degree and actually perform a moving Lydian improvisation.

Such a skill is difficult to acquire and, once you have it, it is hard to help others reach a similar fluency. Once something took you some time to learn something and you practice this on a daily bases until you finally have it, it’s hard to remember what ignorance was like.

(I can’t go back to a single monitor setup, my guitar teacher is surely aware of how the world changes the more you know where scales and arpeggios are on the guitar and how they sound, but it takes it time to rightly guess how much it will take me to get there and feel comfortable about something).

Corey Doctorow has a nice quote to explain that with references to Regular expressions, or regex or regexp:

“Knowing regexp can mean the difference between solving a problem in three steps and solving it in 3,000 steps. When you’re a nerd, you forget that the problems you solve with a couple keystrokes can take other people days of tedious, error-prone work to slog through.”

(I guess we don’t have to blame our teachers. We are asking questions that are as hard as “how was it when you couldn’t read English?” or “how did you learn the multiplication table of 5?”.)

The more you spend time coding and learning, the more it seems that Yoda strikes back:

“Aspiring or great programmers. There is no in-between” (Photo by Nadir sYzYgY on Unsplash).

So let’s explore this feeling and this “ok, I know my syntax, I did some projects, where do I go next?”.

I approached the task of exploring and reporting on these Python’s mysteries thinking 2000 words would be enough. Fail. I realized the document was getting way too long and had to break the mysteries and difficulties into parts.

Let’s think out loud about this process and identify the sources of things being mysterious. Accomplishing the extra parts is way more complex, but it’s good to sketch a plan and have a map of what we need to conquer.

Vocabulary

Python has its specific jargon, this can be mysterious when we first start studying it. This can be easily fixed developing a vocabulary or looking for one. That’s the reason why books have indexes, recaps, and lists of definitions or key terms.

It is way too easy to use acronym or Python jargon. It makes us sound proficient, it is cool, it lets us save time. But before we get into this puts us off. ‘Cloning’ and ‘forking’ might be intimidating for new git users.

Python has its fair share of ‘PEPs’, ‘BDFL’, ‘dunder’, ‘zen’, ‘REPL’, etc. This is probably the easiest gap to fill. You’ll solve this issue by building a reference dictionary. Here’s a nice learners’ glossary on github;

Coding for others

Sharing code with others is a complex process but it’s part of the business. As they we read multiple times “code is most often read than run”.

Entering into the mindset of coding for others (or with others in mind) is complex. First, it requires us some confidence in what we are doing. Then it forces us to explore many other issues like:

  • how to proper code for readability;
  • how to follow standards;
  • if we are passing a script to our non-techy friends (how can them be our friends, then?), it gets us into freezing code or building apps.

Isn’t this all too complex? I mean, we are already trying to learn how to code.

The more you get into readability concerns, the more things are there we need to care about. Here are some sources of mystery related with readability and sharing code:

  • coding styles: things like PEP 8 and other formatting recommendations. What and how we indent, how to prompt readability, CamelCase vs. snake_case, etc. There are standards out and a good Integrated Development Environment (IDE in jargon, i.e. PyCharm or Spyder) may help;
  • writing comments or type annotations or assert statements to check the sanity of our code: those things require some time to sink in. You learn the book and would think “hey, it’s obvious I can read my program. I know the syntax and I know what I’m doing. It was such an effort to get to this print(‘Hello world!’). Then you see your code in two days and… what was that?

Flash forward. This happens the more you learn: from procedures to functions, from functions to classes, from a framework to another to “hey, this trick works way better”. That’s why you need comments and some sort of test.

The good part: type annotations will teach you more about data structures. Writing checks trains your abilities as a tester.

  • testing in generals: testing is a beast on its own. Automation and testing, code coverage. Theres’s a lot more to learn that goes beyond version control systems (like Git);
  • Pythonic ways of doing things: this is when coding styles and conventions start having consequences not only on the eyes of the reader but also on the runtime of our program. For example, we are checking two lists running two for loops and checking that item in list one == item in list two, rather than using a single for loop on the first list and check if the items we are iterating over are in list two. Another example can be that of using bad import practice that are more error prone, like creating conflicts in namespace.

Those are hard to figure out because ‘Being Pythonic’ is something you can achieve once you sort out some of the mysteries. It means you:

  1. have an understanding of how things work;
  2. can solve the task in different ways;
  3. knows what is it like to be Pythonic (a mystery in itself);
  4. are able to evaluate which of the implementations in 2 is the most Pythonic.

This leads us to another big topic.

Python Specifics and Internals

These thinks are hard to learn. Ok, an intro book will tell us about import this and the Zen of Python. That’s for sure part of the essence of Python and its “spirit”, as are some other things that are beginner friendly like the fact that white space is important.

The specific and internals we are talking about are those that will have an impact on performances. Or maybe we are talking about what makes the language you are studying (Python here) different from another language (you have no idea about). We need to be aware and detect “code smells” (another piece of jargon). That’s tricky.

I mean, we are already studying the features and the language. Maybe, depending on your book and sources, part of these are not presented to you as they might mess around with a more user-friendly learning curve.

Nonetheless, this work in a safe environment of an introduction or a book. Then we go out into the wild and some of these things really start to have an impact. And we have no guidance.

Here are some of the possible sources of concerns: naming, scope, flow logic, python design (GIL, threading), functions and class, python data structure and data operations, comprehension. Other things like shebangs line or main calls.

Being Pythonic

We have seen this already (twice), but it probably deserves an entry on its own.

Pythonistas use their own language, their code is cool and Pythonic. Still, getting what it means for code to be ‘Pythonic’ is hard if we are starting out with Python and if you have no exposure to other programming languages.

In fact, a perfectly good explanation like: “This is so Java, you see, you initialize the counter of the loop and then go into it updating. This smells Java. Python has a built-in enumerate() function to do that. Not to mention comprehensions…” is quite hard for us to get if we have not enough experience with the comparison language.

We can try to fix this learning something from other languages. And, when you are there, trying to implement something in your new language (say Java) into your old one (Python).

That’s a good way to start comparing things, get a feel for Pythonic ways as well as alternative solutions and implementations.

Blackboxes

Blackboxes are another issue. Python is so good with all its modules and functions. This leads to another problem: trust Python modules or internals to do our work. We trust some code on stackoverflow or something similar.

We are doing something we know it works, but can’t explain why. This is harder to solve. It requires reading the docs and having a look at the internals. But when we succeed, knowledge is built.

Was this interesting? Feel free to connect over on Linkedin or join broader conversation over Twitter (expect some fantavolley struggles).

This work is carried out as part of a CAS Fellowship as CAS-SEE Rijeka. See more about the Fellowship here.

--

--

M.A. phil. Ph.D.. Now in tech as a programmer. I send random stuff in your inbox https://1110sillabo.substack.com/ Guitar player, digital gardener and more.