Things I Wish I Knew as a New Python User

Photo by Prasad Panchakshari on Unsplash

Last week I responded to the weekly #DevDiscuss with a long thread about Python, and this post is the refinement, expansion, and all-around long-form expression of those same ideas. These are all the all the things I wish I knew when I was just starting to use Python, with the benefit of hindsight.

Basics

There are a million and one tutorials out there to get you up and running with the syntax.

Pick any tutorial written for Python 3.6+ and ignore anything written for Python 2. Python 2 is deprecated. They are not all the same, so sample some, and devour at least one deeply. Revisit a few times. FreeCodeCamp wasn't on my radar when I learned Python, but it comes highly recommended. They seem to have a very robust Python course.

Do not expect of yourself to memorize every syntax rule. Many (most?) developers still have to look things up after many years of working with a language, including me.

Read PEP 8 and PEP 20.

PEP 8 is the style guide. Tools like Flake 8 and Black will help you adhere to it easily. Don't follow it blindly!

A foolish consistency is the hobgoblin of little minds. — PEP 8

PEP 20 is the Zen of Python, which you can refer to whenever somebody tells you something nonsensical with the word "pythonic" mixed in. (We can joke, but the truth is that Python has the power to be beautiful, and that matters to me.)

Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than right now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!

It has been years, and I am still learning to write code that embodies these ideas.

Tools

Spread your investment in your environment out

I will never settle on a "perfect" IDE configuration.

DO: Install the basic Python extensions for your code editor, plus some productivity/workflow extensions like Git

DO: Try out package-specific extensions for packages you'll be using

DO NOT: Get stuck editing your IDE into a complex configuration that distracts from writing code

Use this excuse to learn git if you aren't already

Eventually, you will want to share, collaborate, or reuse your code, and then you will want something like Git. I have never heard a developer say "Dang, I wish I had never learned git". In the past, I have been a partisan against anything but the git CLI, but I was wrong. I still think it's hard to learn the concepts without going to the command line, but if you can do it in the IDE or a desktop client then go for it.

The Standard Library, and Other Packages

stdlib is a gold mine. sys, os, json, asyncio, http, uuid, unittest, and so many more! Find them all here. These libraries are preinstalled with Python!

Beyond stdlib there's a whole universe of packages. Python has one of the most vibrant and awesome ecosystems around. This awesome list organizes a bunch of those libraries into categories for you, and there are many more out there for you to find on PyPI. You can do it with pip!

• pip install mypackage1 mypackage2 mypackage3 to download your packages

• pip freeze > requirements.txt to save your installed packages to a file (the file name is conventional)

• pip install -r requirements.txt to install all the packages in requirements.txt

Practices

Use and dispose of virtual environments often

Python uses "virtual environments" to isolate dependencies. You can use anything you want, and I like Poetry a lot, but on Linux I generally start a new project with a simple set of commands:

git init my-py-project cd my-py-project python3 -m venv venv source ./venv/bin/activate 

There is a repo of starter .gitignore files maintained by GitHub including one for python. It already includes your venv file. Copy it into every project. Never look back.

Last thing to note: you probably don't need conda. It's a really great tool, but some folks start out going straight to conda but I think Poetry or venv is enough for now.

Static Type Checking

With mypy, you can add static typing to Python. Famously, Guido Van Rossum, the creator of Python, led a team at Dropbox to add mypy type checks to four million lines of code. New versions of Python have been adding language features that complement type checking.

For quick, one-off projects, you might skip mypy. If you're going to be working with a project for a significant period of time, static type checking can eliminate entire categories of errors from your Python.

Documentation is a Superpower

PEP 257 and a few others define "docstrings". Leverage them to make full use of autodoc tools. pdoc is a pretty fun tool that "just works". Build good habits from the start. Projects that have great documentation are just more attractive to me. If I come across a project that seems to do what I need, but has crappy documentation, I keep looking.

Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else. — Eagleson's Law

Thank You Python

I love python, it has given me so much joy and I owe it so much. I hope more people learn and love python.