This post originally appeared on the The Slip Box
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 inrequirements.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
Python has truly changed my life. No kidding. I love python, it has given me so much joy and I owe it so much. I hope more people learn and love python.
Photo by Prasad Panchakshari on Unsplash
Top comments (2)
Hey Charles,
Nice article.
You brought up some new ideas for me. Static type checking(
mypy
) and docstring tools(pdoc
) were new to me. And, you are right aboutgit
.I am not sure I understand your comment about
conda
. Maybe you could elaborate. I happen to like Anaconda, but I do realize it is an elephant gun for a mosquito. I also feel that it adds Magic where there should be no magic just understanding.I do have one 'beef' with you. lol The 'Zen of Python' was one of the first things I read when I grabbed a Python book. Frankly, it puzzled me. I have studied Buddhism enough to know 'there are things that cannot be taught.' What puzzled me was there was never any mention of it again. It was a pie in the sky item that was not really discussed in any book or learning system, that I know of. To me, the beginner is left with too many unanswered questions. There were very few concrete examples that I could pick up. I guess that is what Koans do. However, I never felt that the zen method of teaching was beneficial to most Americans or me. ;)
Thanks ;)
Great point, I think pep 20 is probably the most concise statement of Python "culture" and that's definitely not useful for all comers.