I’ve been thinking about the Tao of Python. It’s a tricky thing to pin down. The Chinese concept of Tao is, in itself, famously hard to grasp and, therefore, to translate. It’s sometimes glossed as “the way” or “the path.” But what I’m aiming at here is to explain (at least to myself) the spirit of this programming language.
Why? Because I suspect it’s easier and more motivating for the beginner to learn a new computer language if they have a feel for the essential aspects of it, aside from the strictly technical details. These days, amid the plethora of language choices, adopting a new argot is like learning a new culture. If you divorce the technical details from the culture, you likely suck a lot of the enjoyment out of coding.
This will feel like pure sentiment to some people, who view any code as little more than a tool. Does one wax poetic over one’s hammer, drill or soldering iron? Probably not. But computer languages feel different, and it seems to me that Python brings out more emotion in people than do most other languages.
The Yin and Yang of Python
I’ve found that, like anyone else, Python has a lighter side and a darker side. When you go to python.org in order to download it, poke around for a bit to get a feel for what else is there. It’ll give you an idea of what I deem the yin and yang of Python world.
by Klem
The yin represents of the soul of Python: that is, the ideals, the culture, the community and overall vibe. It’s the kind of stuff that helps motivate you when learning a language, but it’s usually given short shrift, if mentioned at all, in books or tutorials.
The yang, on the other hand, is the body of Python: that is, the coding details, the documentation, the references, the tutorials, bylaws and sundry other particulars. It’s the kind of stuff that’s usually the subject matter of books and other resources.
So, why don’t more books and blogs focus on the yin? Two reasons, I think. First, a lot of committed coders have already bought into the yin. They’ve often been coding since they were wee lads and lassies. The yin is the air they’ve been breathing, so they don’t need any discussions or celebrations of it. Second, coders tend to be practical folk. They want just the facts, ma’am, because they want to get up-to-speed on a new language as soon as they can, often in order to get a specific project done.
But the true beginners? We want facts, sure, but we also want to believe we’re doing something fun and worthwhile in a world rife with countless other ways to spend our time. We need, in short, to be converted to the Church of Coding.
The Yin
The Community
At the soul of Python is its community. You can get a feel for it at python.org, where there is a large section called (what else?) “Community.” It provides practical information on conferences, workshops, awards, user groups, etc. But I think that the Python community goes beyond the stuff appearing on that page.
From a wider perspective, the community is made up of folks who go to the trouble of helping each other solve problems in many different forums. Stackoverflow.com, for example, is “a question and answer site for professional and enthusiast programmers”; I’ve found that it’s a great place to gain practical insights into Python (among other things).
There are also face-to-face meetings, though they can be harder to find. Many cities now have makerspaces/hackerspaces where people congregate to make stuff, teach one another to code, and otherwise fly their geek flags. There are also meetups and user groups in which people come together just to discuss programming in Python. And there are a number of Python-focused conferences in a given year.
The Open-Source Vibe
There’re are bound to be communities built up around just about any computer language, but Python has a certain idealistic vibe about it due to its origins and licensing. After all, Python is free and open-source, otherwise known as FOSS. You can download it onto your computer for free, but “free” has another meaning when it comes to Python. That is, you’re free to copy and re-use it.
As for the term “open source,” it means that that people can have access to the source code – that is, the computer instructions written in a human-readable computer language. There are other criteria associated with open source as well. In fact, the Open Source Initiative includes ten different criteria, including ideas such as that an open-source license “must not discriminate against any person or group of persons” and that it must not “restrict anyone from making use of the program in a specific field of endeavor.”
There’s a sort of practical idealism here that, in other situations, might be sniffed at as some sort of Commie-Socialist-New-Age craziness. But toward the end of the 20th and beginning of the 21st centuries, open-source software changed the landscape of the software industry, “turning it from a mostly capitalist economy into a mixed one,” according to the The Economist.
Open source has become a critical part of today’s businesses. Indeed, we now have articles from consulting groups explaining to businesses “Why You Need an Open Source Software Strategy.”
Bottom line: the Python vibe is unique but is influenced by the larger open-source ambiance that has radically altered the software landscape. You get the sense this stuff is going to have much more lasting legacy than the communes of the 1960s.
The Way of the Python Programmer
There’s an aesthetic associated with Python programming. I think it applies outside the Python community as well but is especially associated with it. It’s nicely summed up in the following guiding principles developed by Tim Peters:
The Zen of Python
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.
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!
There’s a combination of humor and wisdom here that seems especially “Pythonic”. You can just write “import this” into your IDLE and you’ll find that the poem is printed directly into your console!
Mischievous, fun, practical and beautiful: it’s all part the Python aesthetic.
Another place to pick up on it is at the geek-beloved webcomic xkcd, Here’s one of the more famous Python-focused comics:
But there are also some other great ones related to Python such as New Pet and Electric Skateboard. It’s whimsical geek humor at its best.
The Yang
Despite the fun, whimsy and camaraderie associated with the yin of Python, Python isn’t some New-Agey all-inclusive drum circle where even the rhythmically challenged are welcome. At its core is the serious computer language that is used to build software on which businesses and sometimes even lives depend.
If you’re a beginning coder, think of yourself as a lion cub. You play around a lot, mixing it up with the other cubs, stalking insects, watching your elders bring home the big prey. Most of your playing around, however, serves a serious purpose: getting skilled and strong enough to move beyond wrestling with kittens and eating bugs. You want to eventually engage in the serious art of hunting and killing gazelles (or whatever) and battling dangerous threats when needed. In short, all that playing around had a serious purpose.
In the human world of coding, there’s no reason you can’t stay a cub forever, as long as programming isn’t required to make your living. You can fool around with Python tutorials and games to your heart’s content. But there are plenty of folks who use Python and other languages to not only earn their bread but to tackle some of the most important problems in the world. Python is a tool for creating solutions to those problems, solutions that programmers refer to as algorithms.
The terrific book (which has an interactive edition) How to Think Like a Computer Scientist defines an algorithm as “a step by step list of instructions that if followed exactly will solve the problem under consideration.” So, you’re taking those instructions and putting them into a language (in our case, Python) that the computer can understand. Once you’ve done that, you have essentially automated the execution of your solution to a given problem.
Bottom line: this process requires precision, which is one reason coding has much bloody documentation. If you don’t sweat the details, your code just won’t work properly. For people who are used to the creative ambiguity of human languages, this can seem persnickety and anal and just no frigging fun.
Poetry, for example, thrives on artful ambiguity and multiple meaning. Coding doesn’t. Computers are literal creatures. They need things properly and exactly spelled out. It’s their way or the highway. This deep need for structure, logic and rigor can be thought of as the yang of Python.
Speaking in Tongues While Handling Snakes
Python demands that you obey its internal logic. To do this, you need a crystal clear understanding of how it works. The good news is that the language itself is pretty darn lucid, perhaps better than any other computer language. The bad news is that good coders can be rotten writers. That is, they can fail miserably when they write for other people, especially beginning coders.
I think that a lot of the documentation in the otherwise excellent python.org website is a case in point. It’s sometimes like trying to parse some awkwardly translated instruction manual when trying to put together a new grill set. Or maybe like striving to grok Stéphane Mallarmé’s symbolist poetry:
Nothing, this foam, virgin verse
Depicting the chalice alone:
Far off a band of Sirens drown
Many of them head first.
You want to yell, “Speak the English!”
This is clear even to some Python experts. Giving a short talk at PyCon, the largest annual Python-related conference, Python instructor Simeon Franklin asked other Python professionals to take a close look at information on the python.org site in regard to specific features such as “docstrings.” He says that, if those professionals didn’t already know what these features were, they’d have a tough time gleaning it from the text. He urges them to look at such information with a “beginner’s mind.”
But that can be hard to do for many experts. As a result, it’s as if somebody got filled with some holy spirit of coding and started going all glossolalia on us, speaking in Python tongues. If I were a tad more paranoid, I’d think the documentation were intentionally designed to obfuscate the esoterica of the erudite, to bewilder and baffle the benighted seekers after coding clarity and light. Here’s an example of what python.org reports tells us in section called “What is a Docstring”:
A docstring is a string literal that occurs as the first statement in a module, function, class, or method definition. Such a docstring becomes the __doc__ special attribute of that object. All modules should normally have docstrings, and all functions and classes exported by a module should also have docstrings. Public methods (including the __init__ constructor) should also have docstrings. A package may be documented in the module docstring of the __init__.py file in the package directory.
Um, okay. Sure thing. Uh huh.
Look, as a beginner, I’m not going to have much of a clue about what distinguishes a module from a function from a class. And alluding to the __init__ constructor just seems cruel, as if someone were giving you their phone number in Morse code.
Now here’s how Swaroop C H puts it in his book A Byte of Python:
Python has a nifty feature called documentation strings, usually referred to by its shorter name docstrings. Docstrings are an important tool that you should make use of since it helps to document the program better and makes it easier to understand. Amazingly, we can even get the docstring back from, say a function, when the program is actually running!
See, was that so hard? He then goes on to show examples of what docstrings look like in some easy code.
The bottom line is pretty simple: programmers use docstrings to tell one another what various blocks of code are supposed to do. Yes, there are other relevant details, such as where to use docstrings and how to format them, but those nuances are less important to the beginner than answering the basic question, “What in the hell is it?”
All the documentation on python.org is supposed to bring light to users with questions. Sometimes it does, being very rich in detail. But to the beginner, it often feels more like dense, dim thickets through which we have to machete our way. Ah well. In the case of particularly dense thickets, there are usually other sources of information in books, tutorials or on the Web. You’ve just got to figure it out. After all, yang happens. It’s all part of the path.
PS – The Python community has, to its credit, become more accommodating to beginners over the years. For example, here are Python Frequently Asked Questions geared toward beginners.
Feature image by Rolf Dietrich Brecher from Germany. See https://commons.wikimedia.org/wiki/File:Yin_and_yang_(36365569814).jpg