$ python -c "import this"
The Zen of Python, by Tim Peters
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!Gur Mra bs Clguba, ol Gvz Crgref
Ornhgvshy vf orggre guna htyl. Rkcyvpvg vf orggre guna vzcyvpvg. Fvzcyr vf orggre guna pbzcyrk. Pbzcyrk vf orggre guna pbzcyvpngrq. Syng vf orggre guna arfgrq. Fcnefr vf orggre guna qrafr. Ernqnovyvgl pbhagf. Fcrpvny pnfrf nera'g fcrpvny rabhtu gb oernx gur ehyrf. Nygubhtu cenpgvpnyvgl orngf chevgl. Reebef fubhyq arire cnff fvyragyl. Hayrff rkcyvpvgyl fvyraprq. Va gur snpr bs nzovthvgl, ershfr gur grzcgngvba gb thrff. Gurer fubhyq or bar-- naq cersrenoyl bayl bar --boivbhf jnl gb qb vg. Nygubhtu gung jnl znl abg or boivbhf ng svefg hayrff lbh'er Qhgpu. Abj vf orggre guna arire. Nygubhtu arire vf bsgra orggre guna evtug abj. Vs gur vzcyrzragngvba vf uneq gb rkcynva, vg'f n onq vqrn. Vs gur vzcyrzragngvba vf rnfl gb rkcynva, vg znl or n tbbq vqrn. Anzrfcnprf ner bar ubaxvat terng vqrn -- yrg'f qb zber bs gubfr!
It's incredible how every single thought you think it's yours was already had a bunch of times.
(https://en.wikipedia.org/wiki/Zen_of_Python has more about the discrepancy.)
$ python -m this # -mthis works tooThe joke is that people wanting to write Python like Java - with an implicit reference to an object's instance - would attempt to import Java's `this` keyword.
Instead of getting Java-like behavior, they're presented with the Zen of Python. You wouldn't be wrong to think that it was as much a commentary on other popular languages of the day as it was a guiding ethos of Python itself.
"Beautiful is better than ugly. Explicit is better than implicit."
Pretty much all of this critique applies squarely to the Zen of Python.
Together, what that's saying is that sometimes the minimal baseline complexity is going to be pretty high. If you're making a library to support all of HTTP/2, it's going to have lots of codepaths, and that's unavoidable. It's a complex problem requiring a complex solution. But consider SMTP, the "simple" mail transfer protocol. The protocol itself is stupidly simple. I can use — and have used — telnet to port 25 to send email. But because the protocol is so simple, implementing it is extremely complicated. Were the protocol a little more complex, the implementations could be vastly simpler.
Or perhaps more simply, if you're writing a textual protocol, define it as using UTF-8 encoding and move on. UTF-8 is more complex than simpler encodings like ASCII. Allowing your clients and servers to decide that they'd rather support something goofy, like Shift JIS or UTF-16, just makes everything vastly more complicated. Accept that the complexity of UTF-8 is inherent and sufficient, pay the cost, and then let all of your consumers be much simpler.
Complicated = a solution that's difficult to understand due to a convoluted implementation. These can be simplified.
In other words, the difference is whether the difficulty is inherent to the problem space (complex) versus inflicted by a solution (complicated).
Complex - many parts (but the parts could potentially be simple) Complicated - have to understand many things in order to understand it at all; large surface area
But if you know somewhat what implication a particular writer intends in drawing a distinction between the two words, then there's no inherent problem. "Simple is better than complex. Complex is better than complicated." is a pithy way to express a valuable idea:
We should try to make our interfaces, data structures, implementations, systems, etc. "simple", that is, dealing with just one thing at a time, in a clear and straightforward way, with few components each with a well defined purpose, etc. Sometimes, however, there is inherent difficulty in a problem or in the world requiring many interacting pieces, but we should still aim to avoid making things "complicated", that is, tangled, messy, difficult to reason about, ambiguous, unpredictable, gratuitously mixing unrelated concerns, etc.
If something is complex, you have to deal with it. But to complicate things is to be avoided.
I guess if you take the square root of -1 you do get a complicated number, but it's a complex one. And then there's the complication for modern democracy called the military-industrial complex, and Oedipus's complex certainly complicated things. Then there's Ghost in the Shell: Standalone Complex, but I'm not really sure what that means.
Seriously, here's the best summary I can quickly find: [0]
"Complicated problems can be hard to solve, but they are addressable with rules and recipes, like the algorithms that place ads on your Twitter feed. They also can be resolved with systems and processes, like the hierarchical structure that most companies use to command and control employees.
... Complex problems involve too many unknowns and too many interrelated factors to reduce to rules and processes. A technological disruption like blockchain is a complex problem. A competitor with an innovative business model — an Uber or an Airbnb — is a complex problem. There’s no algorithm that will tell you how to respond.
This could be dismissed as an exercise in semantics, except for one thing: When facing a problem, says Nason, managers tend to automatically default to complicated thinking. Instead, they should be “consciously managing complexity.”"
Those are very different problems for software development too, and many in IT definitely try to treat every problem as complicated.
[0] https://sloanreview.mit.edu/article/the-critical-difference-...
Oh boy, that didn't age well for Python language did it? It matches with C++ in growing complexity of syntax features. With a couple dozen ways to write the very same algorithm.
Every primitive type has a null value, and the "if" statement tests for such a value. Whether a value is true or false is a property of the value. Notice that "true" and "false" are adjectives, not nouns.
That is a simple, internally consistent model with one concept of trueness.
The introduction of the boolean type made this a lot messier: it makes "if" look like type coercion, and introduces two different ways to think of boolean-ness (as an adjective or as a noun) which you must hold in your head at the same time. For example, it became possible to compare things as equal to True or False, doubling the number of ways to express a condition: "if x" and "if x == True" are now very similar, but subtly different, ways to express the same thing. The fact that we have to talk about things as "truthy" or "falsy" as if these were different from "true" and "false" is a further illustration of the mess this has created.
If we had stuck with 0 and 1, we would have avoided all this confusion. It is imperfect but simple; what we ended up with is still imperfect and needlessly complicated.
The addition of boolean `True` and `False` were a huge improvement to the language when they were finally added in 2.3.
I'm not sure why you're making things more complicated than they need to be. Test for truthiness. Conditional statements already evaluate boolean expressions, you're not adding anything explicit by writing `== True`.
I am not sure if that perspective aligns with yours.
In an explicitly, statically typed language, bools might be useful as a standard small enum.
In what Python used to be, they weren't, not really.
But for whatever reason, declared typing is now an add-on to the language, and the people who like the verbosity of declared typing also, perhaps schizophrenically, like the terseness afforded by having a standard small enum.
.
(EDIT: Robert Woodhead apparently shares in the credit, too: https://www.ceas.cc/papers-2004/136.pdf https://ceas.cc/papers-2004.html . Apparently Rob Hooft was another implementor? I can't find a good source for that though.)
The reason that's especially interesting is that I was using an AI to write something that needed that functionality, and it spewed out that same Python code, which I recognized immediately. It was slightly modified with respect to naming and comments because, I assume, it was stored slightly imperfectly in the model's weights.
This is what engineering is all about. Applying what it long known to solve new problems, or old problems better.
LLMs are a triumph today because someone made a keystone observation
Another thing that made me feel close to him was his work on the Python Cookbook 2nd Edition, in which he (and other big names in the community) delightfully talks the reader through intricacies and insights of programming, "We read Knuth so you don't have to".
Watching Tim do his thing was a pleasure. He'd go from long, deep technical dives (that he'd make as approachable as possible) into comic relief and human connection in the fractional wink of an eye.
The brief interactions we had will always be cherished as high points in my Pythonista trajectory.
One favorite of mine was this response: https://www.python.org/doc/humor/#id15. I also like https://www.python.org/doc/humor/#id19 very much.
https://groups.google.com/g/comp.lang.python/c/DfzH5Nrt05E/m...
> if-tabs-were-called-hemorrhoids-as-god-intended-people-would-see-them-for-the-bloody-mess-they-are-ly y'rs - tim
I was an active participant in the comp.lang.python Usenet channel in the late 1990s.
I learned much from reading Tim Peters' posts. To many, including me, he was affectionately referred to as "Uncle Timmy."
One of the things I learned was that I still had much to learn about the art of programming.
Much of the little I know about numerical methods comes from reading his posts. It was fun to read his stories about Kendall Square Research and the (for me) old days of computing.
I remember posting questions about things I didn't understand, which he figured out and explained. [1]
I remember bringing up concepts I thought were specialized and esoteric, only to find that it was actually just my lack of experience. He gently corrected misapprehensions like mine. [2]
He wrote a lot on comp.lang.python. If I recall correctly, at the 7th International Python Conference in Houston, November 1998, there was Festschrift in his honor. He would use <wink> in his messages, and often end with something like "let's-hear-it-for-lambda-in-curly-assignment-stmts-ly y'rs - tim" (that's from the posting where he outlines the Zen of Python). I wondered if they were collected by looking for messages containing an '-ly' only to have Andrew Kuchling remind me about the "From" header. <wink>
Here is Guido van Rossum starting the thread on "In Memoriam: Tim Peters", at https://discuss.python.org/t/in-memoriam-tim-peters-1952-202... .
Here's an interview of him at PyCon 2006, https://www.youtube.com/watch?v=1wAOy88WxmY
[1] In one case, I was parsing a file format where a field was usually three spaces, but was sometimes an integer. I couldn't figure out why one parser was so much faster than the other. The answer was that one tested for three spaces first, and if that failed tested for the int, while the other did the int test first.
Yes, this is something a senior developer knows. I bring it up now to highlight how hotshot-me didn't have that experience, learned that experience, and learned it from someone who was kind about sharing his knowledge.
[2] I was doing bioinformatics back then, and learned about dynamic programming as way to do sequence alignment. I didn't think others knew about the technique, and thought I was bringing esoteric new information to the discussion. Uncle Timmy had used dynamic programming techniques for speech-to-text software at Dragon Systems, and politely pointed out it was more widely known. He also implemented Python's 'difflib'.
He was always so willing to foster discussion that nearly every interaction resulted in an improved understanding of some topic and a shared eagerness to try or learn more out something tangential that came up via digression. I never knew how many types of voting systems there were nor how extensively they are researched! He also reached out about a comment [0] I made a few years ago which made me feel less discouraged and more welcome.
Tim's writing style was greatly appreciated by myself and many others. What he had to say was often lengthy, to address reader assumptions or some nuance, but was written with such a jovial tone that it was rarely dull or inaccessible.
RIP Tim
I like reading his answers. He always seemed to have something interesting to say, and his answers are kind, light-hearted, approachable and insightful.
At the time I didn't realize it was the Tim Peters. Very helpful guy. RIP
For me, Tim Peters was that guy. I first met Tim in person at the first PyCon at GWU where I rode an elevator with him and Barry Warsaw. Let me tell you, it was a wild ride. He was a genuinely really nice, smart, kind guy.
RIP my friend.
You never know when an email is going to be the Last Email. Don't put off reconnecting with old friends.
And after that three months suspension BS drama Tim just got back to work on Python. Saintly.
btw. made me stop having a favourite programming language.
They can keep the tools & remix new ones with LLMs. The rest of us can hang out in some tiny corner talking civilly.
When we find ourselvees thinking that, then we are part of the status quo - the system is designed to suit us. It's very easy to think that status quo is the entire universe; just keep doing what you're doing. Instead, to avoid perpetuating the bad aspects of the system, it's essential to curiously and closely look for its boundaries, look outside it, notice the humans out there who are not being served, who may express unhappiness.
Take them at their word; they may seem absurd, but that's your human response to someone violating norms - the norms being the status quo. Their expression may include being disruptive or unpleasant. 'Disrupt' means 'violate the status quo'; it shows you the status quo's limitations.
It looks like you (plural) bring it up only to push your political agenda against Woke or whatever.. while people are mourning and I find it frankly distasteful and an insult to his memory.
This whole episode certainly reflects very badly on PSF SC. But it is not a very glorious event of Peters' life either, and it feels better to just not uselessly stir the pot in a way that makes Peters not look good.
(and again, to be clear, PSF SC looks even worse, but of course the point is to remember Peters for what he was, not to profit of his passing to score points against PSF SC)