Before I clicked into the link I mentally thought "Wait I hope it's not the guy who invented Tim Sort". Very sad. Trying to retain hope that newer generations of Python folks will keep the zen of Python alive but especially in an agentic era, to some degree that hope does feel less and less realistic by the day.
$ 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!
I discovered this early on in my programming journey and it helped set my philosophical trajectory. Over the years I’ve slowly grokked these items. But it was valuable to have a North Star even before I realized why they were important.
Oh same, same. They didn’t all land at once but I remember multiple times I ran import this because I was bored or finished at the end of a day and thinking, “Oh yeah, I figured that out since the last time.” To me, it was a formative document and I can’t say enough good things about it.
Interestingly, today this text reads not only as good advice for coders but also as good instructions for agents. Perhaps time to revisit those and make sure the spirit of these adages is captured there
> There should be one-- and preferably only one --obvious way to do it.
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.
Python has never followed the Zen. The irritating way the language lets you use non-booleans in a boolean context flies right in the face of "explicit is better than implicit".
This will probably sound crazy to some of you, but I believe the introduction of the boolean type was a mistake.
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.
Booleans are reductionist and likely harmful, as they allow programmers to avoid thinking in terms of the test they are actually performing: is this a member of some set? If the problem is reworked like that Booleans are superfluous (this representation could be compiled to something as performant as using Booleans).
I am not sure if that perspective aligns with yours.
Not sure why you're getting downvoted so much, but to put this thought into a somewhat broader context:
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.
I still have a printed stack of Python 1.5.7 docs from when I first learned the language.
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`.
Does it? "bank account has 0 dollars" and "no bank account" are different states. 0 cannot (should not) try to represent both. Same for empty string, empty list, empty set, they are data not nulls. Python has None for that.
But None has its own type; it's not a value of any of the other primitive types. Which makes sense if you use None to represent "no data present" vs. "data present, value is the null value".
> If we had stuck with 0 and 1, we would have avoided all this confusion.
I don't see how. Indeed, using 0 and 1, the int values, as if they were boolean false and true created more confusion. First, int has more values than just 0 and 1--and all of them are "truthy". Second, treating 0 and 1 as booleans is still treating boolean-ness as a noun--but also confusing that with treating it as an adjective for those int values.
PEP 285, which introduced the bool type, gives other rationales as well:
That's because the Zen is a collection of fuzzy aphorisms about taste. Python has in fact never had a set of hard principles that constrain the design of the language.
In other traditions, type systems or the borrow checker or even vaguer things like a commitment to a "tiny core" of just a few primitives constrain language designers in a way that (sometimes inflexibly) commits them to the consequences of earlier design decisions. Python has mostly been designed one step at a time, by fiat. It's not a surprise that the result is an inconsistent language, especially after the resignation of the BDFL, and especially after so many years of widespread popularity.
To be honest I found this sentence to be beautiful and true for many years after working a lot with php and perl.
The mort important word in this sentence is obvious. There are many many many ways to do the same thing but working with python I found that mostly to be true, there is always an obvious, documented way (and not two of three!). Searching for a way to do something in perl, for example, was such a huge difference.
It is really more aspiration, and a good programmer mantra anywhere. Nothing here is so Python specific outside namespaces, and ... that is also a good programmer mantra.
Fourth reply to the article in the link, by Chris McDonough includes:
> "You have Tim to thank at least partially if you were a refugee from Java or Microsoft languages, which made excuses for their sprawling verbosity, complexity, and poor readability. Python, at the time, made none of those and had none of that (it now does). Tim was crucial in ensuring it stayed that way during his most active years. He will claim differently, but, by my observation, it is no accident that Python ballooned in complexity after his exit as day-to-day core developer."
It's to ensure the text is never altered because altering it would require reverse engineering the encryption algorithm which is a felony. (This is a joke, and a not-so-subtle criticism of the DMCA.)
The only thing I never liked about this is complex is better than complicated. Every once in a while there is a post with an “insight” on how they’re different, but it’s the same word! Naming things is hard, but I wish Tim found another word for one of these.
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
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.
A complication on a wristwatch is anything other than telling time. Phases of the moon? Tides? Calendars? Complications. They make the innards more complex and fragile and difficult to build and repair. Complexity is the inherent difficulty in building the thing.
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.
The two words are both centuries old, so have had many chances for various authors and fields to adopt them for differing purposes, sometimes in contradictory ways. So for example a "complex system" (in the sense of the Santa Fe Institute) means something moderately different than what Tim Peters means. In plain English, they are broadly synonymous, so if you were writing a newspaper story you shouldn't expect readers to find subtle differences between them.
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 clear structure and purpose, etc., but sometimes 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 complex only refers to inherent complexity (and not accidental complexity and whatever other attributes were used by people before) then how is "simple is better than complex" to be read? If complex is inherent to the problem, does it mean "solve a different problem"?
It's generally a tradition for wise adages to be a little ambiguous leaving interpretation to the reader. I think that's as much a feature as it's a bug. Perhaps he meant it that way.
A lot of words in English are etymologically related but have grown significant connotative or denotative differences since the root word was reintroduced to the language by another path.¹ "Complex" and "complicated" are just such a pair. They are not the same word.
In this case you can think of "complex" as referring to essential complexity and "complicated" as referring to incidental complexity.
----
1: See also, for example: "intention" vs. "intension", "chief" vs. "chef", "hotel" vs. "hostel", "corpse" vs. "corps", "compliment" vs. "complement", etc. Sometimes related pairs do the opposite, entering with distinct denotations and developing overlapping ones e.g., "intellect" vs. "intelligence". Some transitionsl ones still include overlap but have had specialized senses come to dominate, e.g., "dispositive" vs. "dispositional". In that last case, the special legal sense of "dispositive" came to dominate the word (or the other senses became archaic) in a way that "made room" for the more general "dispositional" to enter the language.)
If you wanna get your head around English (or probably any language), the intuition that alerts you to related words is a very useful sensitivity, but you have to learn to absolutely resist the temptation to treat etymologically related words as identical. It's just not how language works.
English seems like it might be especially rich with these "etymological doublets" (thanks ChatGPT, for teaching me this word today). They're really useful for capturing distinct shades of meaning between closely related concepts, which is exactly what they do in this adage from Tim Peters.
You've missed the joke, or maybe you weren't old enough to be learning Python during Java's heyday.
The 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."
Well that's embarrassing. I first learned Java in 1996 and Python in 2000 (1.5.2), predating "import this". I somehow never made the connection and did indeed miss the joke. (But, I never attempting to import this in Java, and wasn't aware newbies did that.)
Funny enough, it was at a startup where I was introduced to Python and the place was probably equally split between Java and Python code. I wrote nothing but Python there and bristled at what Java had already become and yet... I still didn't make the connection!
Haha, yes! Back in the day whether self should be implicit or explicit was a major point of contention. Those who loved Java and C++ found self to be almost as repugnant as Python's indentation-based syntax. I even posted code on the now defunct ActiveState site to make self implicit again:
The revamp of the object model in 3.x IMO justified the design decision more strongly, since now methods are just functions (unless and until munged by the descriptor protocol) and the class is essentially just a namespace for them. (Namespaces are one honking great idea -- let's do more of those!) In 2.x, methods were a separate "unbound method" type even when accessed through the class, even if you explicitly inherited from `object`; with this model, one could more easily imagine special accommodations for `self`.
> The 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.
No, that isn't where the name comes from; the slogan "import this" was chosen for Python in a contest, and the decision was made to stuff the Zen there because it was also importable code. There's no record of who submitted this slogan or what the motivation was. And I certainly never heard of anyone trying to get a `this` keyword by importing an ordinary module; that would make no sense (the closest reasonable spelling would be something like `from __future__ import this_keyword`).
Seriously. None of those lines are actionable in any way. It seems to ruin afoul of its own advice, "If the implementation is hard to explain, it's a bad idea."
Some people (or maybe even most) take it almost religiously. Maybe because of the name.
But the Zen of Python is an absolutely great vision statement, that positioned the language very clearly in comparison to the ones that existed at the time, and was good enough to guide its development for more than a decade.
Still, yeah, you can negate half of those things and also arrive at a good language.
Once upon a time I used to read all python-dev posts and bugs.python.org issues, so I got to follow (and get a feeling of knowing) these people I admired working and discussing together. Tim was always a favorite.
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.
> Ack, on my keyboard I rebound the Tab key to something less annoying: it
deletes a random DLL from c:\Windows\SYSTEM\. OK, OK, version 0.0.2 caters
to stinking tabs. Patch follows.
Gene Hackman's character in Heist says "I tried to imagine a a fella smarter than myself. Then I tried to think 'What would he do?'"
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.
Among his various other works, it was Tim Peters along with Gary Robinson who turned pg's "A Plan for Spam" essay into the successful SpamBayes program: https://www.linuxjournal.com/article/6467 .
This concept of making the best use of any available data to infer useful probabilities seems like a crude form of some ideas behind current LLMs, BUT they (Peters, Graham, Robinson and Woodhead) were doing this work 20 years earlier.
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, slightly modified with respect to naming and comments because, I assume, it was stored slightly imperfectly in the model's weights.
I loved SpamBayes! It’s amazing how effective that was, all those years ago. I never learned Python, but I never had trouble using it to build small useful scripts. I never knew I had Tim to thank for both.
I have the Zen of python printed out on our office wall and everyone quotes it at least weekly. It started as a bit of a joke, but become a pretty big part of our culture. It's a great set of rules.
Congrats Thomas Wouters and Gregory P.Smith and others for ruining his life work by canceling and humiliating him. I hope your corporate careers benefited from it.
I came to quote this very article. This raised my eyebrows a lot when I originally read it. I always thought that DEVELOPING A DAMN PROGRAMMING LANGUAGE is inherently apolitical and strongly meritocratic endeavor. Boy, how naive I was...
We are naive when we think, as we all do at times, that humans in our <group> differ from the others - they have no politics or biases and aren't affected by those things, and we form some just, meritocratic ideal.
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.
Their is a lot of sociology and other research that suggests that ironically these attempts at stricter social/etc codes mostly arise in communities that don't really need them. this happens for various reasons, but it makes intutive sense if you think about it - thoughtful, well-run communities tend to think about stuff like this. but they also, because of that, mostly don’t need it. that doesn’t mean that that it is true in every case, of course.
As someone formally trained in many forms of dispute resolution, I'll also offer many of these have a significantly misguided view of effective dispute resolution. They often think some neutral and objective group of people evaluating a situation is an effective way to resolve code of conduct disputes, in part out of a desire to be fair and objective. But these are social disputes and not contract or other legal disputes. Applying mechanisms meant for one to the other does not make a ton of sense
> They often think some neutral and objective group of people evaluating a situation is an effective way to resolve code of conduct disputes, in part out of a desire to be fair and objective.
This claim is increasingly difficult to reconcile with an awareness of who gets chosen to evaluate situations, what reasoning they present as "neutral/fair and objective", and how they go about their resolutions.
Post-George Floyd up until Donald Trump was elected, which is when this happened, was peak of this performative bullshit. Like renaming master to main or changing the the name of blacklists and whitelists would end racism, when all this language policing did was make people quietly resentful and was one factor in the backlash that followed.
And when Donald Trump was elected, a lot of the engine of that performative BS switched sides without missing a beat, and we went from corporate pinkwashing to corporate stinkwashing.
I was not aware of this, but I had an experience at PyCon 2022 in Utah where I realized how bad the Python community had gotten and turned me off them. I came to attend PyCon from India, I land up there with vaccination certificates and everything and they would not let me attend. Apparently, two vaccinations and a booster were not sufficient because the booster was 15 days past the 6 month mark. Also, they did not have Covishield (Astrazeneca in India) on their list. While I was rtying to explain this to them beside a wall with some 35 pronoun stickers to label yourself with, the guy would shush me if my mask even slipped a mm below the nose. While at the exact same venue, within the same lobby space, some gymnastics convention for high schoolers was going on and they had no masking nothing at all. It could not be more performative than this. I did manage to get in, but lost half a day.
You people seems to care a lot more than about this event that Tim Peters ever did.
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)
I understand people have strong feeling about that. But I think that the situation is described in a more balanced way in LWN, and, as said on https://tim-one.github.io/psf, I quote, "LWN’s account of Tim’s ban; by far the best “news” article I’ve seen, finding fault on all sides". Peters also produced https://tim-one.github.io/psf/meaculpa where he says he does not recognize the charge against him, but understands why the situation went this way and that it was partially his fault.
So, the situation is more "grey" than Peters being the victim, and I don't think it is a good idea to highlight this in a time where we should focus on Peters. It feels like stirring the pot is just instrumentalizing the event to attack the PSF SC because of unresolved feelings.
Not that this event should be forgotten or forgiven, just that it is not true that it is a mistake it was not mentioned in article talking about Peters' passing. It feels like the idea is that some people don't mention it because they know the PSF SC made a mistake but they want to hide it. But it looks to me that they don't mention it because it makes Peters not look very good on that circumstance.
> where he says he does not recognize the charge against him, but understands why the situation went this way and that it was partially his fault. So, the situation is more "grey" than Peters being the victim
Not in any meaningful sense. The post you cite basically talks about Tim's historical posting style, and then suggests that newcomers to the community might not have been exposed to it, and therefore interpreted https://discuss.python.org/t/for-your-consideration-proposed... as somehow objectionable.
But here's the thing: I first interacted with the guy in 2014 (as far as I can tell) and wasn't part of the Python Usenet/mailing list culture. I didn't really have that exposure either. And yet it was still extremely obvious to me that the post was calling out injustice and not saying anything that any reasonable person could object to. The central argument is that it's unpleasant to be repeatedly subject to training that assumes you need training to behave yourself and not engage in criminal activity, while the wealthy and powerful get away with those crimes. And people who claim to be on the side of "social justice" take offense to that.
If there's some legitimate reason why a morally good person could object to that post, I never heard it floated the entire time, nor in any of the ensuing discussion anywhere on the Internet (and people have accused me before of being unreasonably interested in that discussion). I have only heard people expect me to take it for granted that this, and similar posts, somehow reflect unreasonable behaviour. And because I legitimately can't think of any charitable way to interpret the argument, I don't speculate.
Tim looks just fine "on that circumstance". It is his interlocutors who look completely unreasonable.
(I said you people because I replied to your comment but I was responding to multiple people at once who said similar thing)
Regardless of who was wrong or right, is it the way you would like to be eulogy written about you? bonoboTP was such a nice person and helped so many person and here is a myriad of example to prove how. All that said, I will remind everyone he had a fight a few years ago with some people he worked with and there were not very nice to him. It is just but a pebble in a long fruitful life, but it is really important I mention it here to remind everyone CoC = bad
I know you're exaggerating but that's not what they were saying. You're jumping to conclusions. Ironically, it was the incorrect and bad faith interpretations that were at the core of the whole saga and how the steering council handled everything.
I guess it's indeed awkward. I simply feel an annoying discrepancy. Tim was never properly rehabilitated or apologized to while alive. And now it's just like it never happened.
Stop this "us vs. them" nonsense. This is about basic human decency, which traditionally the moderate left was supposed to have. Now in the U.S. both extremists from the left and right are horrible human beings and corporate ladder climbers.
They are not woke in the first place. The "old white men" keep their corporate positions that they pretend belong to the underprivileged. David Mertz pointed that out and was swiftly disappeared by the Python Gestapo.
What's distasteful is your gaslighting attempt. It's pretty clear from Tim's own writing that he did care.
> While I've since adopted a tedious posting style to avoid triggering newer people, I haven't really changed. I'm not a grim person, and still find humor (sometimes dark) in almost everything. I just keep all sense of joy bottled up now. "Joy is not professional, supportive, welcoming, or inclusive - unless it's joy at the humiliation of perceived enemies of our new Mandatory Utopia" ;-)
[..]
> I would like an apology from the PSF, but don't expect one, and don't insist on one. What I demand is that they improve the broken _processes_ that led to this. My case wasn't the first one of trumped-up fantasy charges, and won't be the last
I'm accustomed to seeing that the unwritten ground rules in places that would criticize me for taking Tim's side, include an absolute prohibition on the use of the phrase "you people" in any context, for any reason, because it is apparently a racist dogwhistle or something. So it's rather galling to see it used by a critic.
We are talking about a political system which seeks to introduce or apply rules that are obviously unfair on their face, justified by inconsistent theories that constantly make hypocrites of their proponents. It is bizarre and unreasonable to call opposition to this a "political agenda".
As one of the people directly involved in the situation, let me tell you: defending my friend's legacy is part of the mourning. His treatment was clearly unjust on its face and now the people who were responsible and/or supported it or advocated it are trying to blend in and pretend nothing happened, while showing no remorse whatsoever. While I'm sure the benedictions they offer now are sincere, I find it mind-boggling that it seemingly gives them no pause to consider what happened. Especially considering the timing (dying around the second anniversary of the original tension, and this being discovered around the time of his reinstatement).
Tim made an entire separate blog site to plead his case, largely motivated by my own posts[0][1]. His "mea culpa"[2] ceded only a tiny bit of ground, and even that was frankly unreasonable. (In the post[3] where he accepted blame, he was explicitly calling out an oppressive power structure, just apparently not the right one.) Not to mention that he was very clearly being "tone policed" by people acting on behalf of the very movement that popularized the term to try to shield themselves.
The insulting thing is to pretend that any reasonable person could ever have seen any merit in the claims against him after any honest inspection of the evidence (to the extent that evidence was presented: the nature of the claims made it clear what public events were being alluded to, while nothing private was ever asserted to exist).
Nobody except Ethan Furman stood up for him. Python-dev is a fascist top-down organization run by creeps. They pretend to be "woke" and "inclusive", but it is all about who gets the easy corporate positions.
Oof, that hits hard. You got me to check; apparently it's been over a year and a half in my case. On the plus side, it involved praising him for his work on faster-than-quadratic int<->str conversion (https://github.com/python/cpython/issues/90716) (which seems to be related to the introduction of Karatsuba multiplication, and to the existence of _pydecimal, although I only really grasped the details in the moment) and getting excited about my then-upcoming blog redesign. Good memories.
Tim was one of the people who contributed to my love of the Python language eventually expanding to its entire community.
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.
212 comments
[ 9.2 ms ] story [ 1062 ms ] threadIt's incredible how every single thought you think it's yours was already had a bunch of times.
.
> There you go: 20 Pythonic Fec^H^H^HTheses on the nose, counting the one I'm
> leaving for Guido to fill in. If the answer to *any* Python design issue
> isn't obvious after reading those -- well, I just give up <wink>.
https://mail.python.org/pipermail/python-list/1999-June/0019...
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.
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.
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`.
Argument by verified hoarder?
> The addition of boolean `True` and `False` were a huge improvement to the language when they were finally added in 2.3.
Hard disagree.
Does it? "bank account has 0 dollars" and "no bank account" are different states. 0 cannot (should not) try to represent both. Same for empty string, empty list, empty set, they are data not nulls. Python has None for that.
Not if you just use the objects as their natural types. For example:
> "if x" and "if x == True" are now very similar, but subtly different, ways to express the same thing.No, they're not. See above.
I don't see how. Indeed, using 0 and 1, the int values, as if they were boolean false and true created more confusion. First, int has more values than just 0 and 1--and all of them are "truthy". Second, treating 0 and 1 as booleans is still treating boolean-ness as a noun--but also confusing that with treating it as an adjective for those int values.
PEP 285, which introduced the bool type, gives other rationales as well:
https://peps.python.org/pep-0285/
In other traditions, type systems or the borrow checker or even vaguer things like a commitment to a "tiny core" of just a few primitives constrain language designers in a way that (sometimes inflexibly) commits them to the consequences of earlier design decisions. Python has mostly been designed one step at a time, by fiat. It's not a surprise that the result is an inconsistent language, especially after the resignation of the BDFL, and especially after so many years of widespread popularity.
> "You have Tim to thank at least partially if you were a refugee from Java or Microsoft languages, which made excuses for their sprawling verbosity, complexity, and poor readability. Python, at the time, made none of those and had none of that (it now does). Tim was crucial in ensuring it stayed that way during his most active years. He will claim differently, but, by my observation, it is no accident that Python ballooned in complexity after his exit as day-to-day core developer."
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!
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
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-...
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.
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 clear structure and purpose, etc., but sometimes 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.
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).
If something is complex, you have to deal with it. But to complicate things is to be avoided.
In this case you can think of "complex" as referring to essential complexity and "complicated" as referring to incidental complexity.
----
1: See also, for example: "intention" vs. "intension", "chief" vs. "chef", "hotel" vs. "hostel", "corpse" vs. "corps", "compliment" vs. "complement", etc. Sometimes related pairs do the opposite, entering with distinct denotations and developing overlapping ones e.g., "intellect" vs. "intelligence". Some transitionsl ones still include overlap but have had specialized senses come to dominate, e.g., "dispositive" vs. "dispositional". In that last case, the special legal sense of "dispositive" came to dominate the word (or the other senses became archaic) in a way that "made room" for the more general "dispositional" to enter the language.)
If you wanna get your head around English (or probably any language), the intuition that alerts you to related words is a very useful sensitivity, but you have to learn to absolutely resist the temptation to treat etymologically related words as identical. It's just not how language works.
English seems like it might be especially rich with these "etymological doublets" (thanks ChatGPT, for teaching me this word today). They're really useful for capturing distinct shades of meaning between closely related concepts, which is exactly what they do in this adage from Tim Peters.
The 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."
Funny enough, it was at a startup where I was introduced to Python and the place was probably equally split between Java and Python code. I wrote nothing but Python there and bristled at what Java had already become and yet... I still didn't make the connection!
https://web.archive.org/web/20211128002836/https://code.acti...
For good reasons, Pythonistas were not appreciative! :)
No, that isn't where the name comes from; the slogan "import this" was chosen for Python in a contest, and the decision was made to stuff the Zen there because it was also importable code. There's no record of who submitted this slogan or what the motivation was. And I certainly never heard of anyone trying to get a `this` keyword by importing an ordinary module; that would make no sense (the closest reasonable spelling would be something like `from __future__ import this_keyword`).
https://discuss.python.org/t/in-memoriam-tim-peters-1952-202...
Pretty much all of this critique applies squarely to the Zen of Python.
But the Zen of Python is an absolutely great vision statement, that positioned the language very clearly in comparison to the ones that existed at the time, and was good enough to guide its development for more than a decade.
Still, yeah, you can negate half of those things and also arrive at a good language.
I focus on how I learned to be a better software developer from him, in both writing better code and supporting others.
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
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.
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
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, slightly modified with respect to naming and comments because, I assume, it was stored slightly imperfectly in the model's weights.
(I've taught the Zen of Python, doctests, timsort, and more during my career.)
1: https://mail.python.org/pipermail/python-list/2000-March/048...
https://en.wikipedia.org/wiki/Timsort
https://commons.wikimedia.org/wiki/Commons:Email_templates#E...
Your corporate sinecure "custom Python distributions" are secure now!
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.
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.
As someone formally trained in many forms of dispute resolution, I'll also offer many of these have a significantly misguided view of effective dispute resolution. They often think some neutral and objective group of people evaluating a situation is an effective way to resolve code of conduct disputes, in part out of a desire to be fair and objective. But these are social disputes and not contract or other legal disputes. Applying mechanisms meant for one to the other does not make a ton of sense
This claim is increasingly difficult to reconcile with an awareness of who gets chosen to evaluate situations, what reasoning they present as "neutral/fair and objective", and how they go about their resolutions.
They can keep the tools & remix new ones with LLMs. The rest of us can hang out in some tiny corner talking civilly.
Unless you are an insider to those discussions you’d not know what was said by whom
Implications that someone should interfere with a process publicly seems wrong as well
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)
So, the situation is more "grey" than Peters being the victim, and I don't think it is a good idea to highlight this in a time where we should focus on Peters. It feels like stirring the pot is just instrumentalizing the event to attack the PSF SC because of unresolved feelings.
Not that this event should be forgotten or forgiven, just that it is not true that it is a mistake it was not mentioned in article talking about Peters' passing. It feels like the idea is that some people don't mention it because they know the PSF SC made a mistake but they want to hide it. But it looks to me that they don't mention it because it makes Peters not look very good on that circumstance.
Not in any meaningful sense. The post you cite basically talks about Tim's historical posting style, and then suggests that newcomers to the community might not have been exposed to it, and therefore interpreted https://discuss.python.org/t/for-your-consideration-proposed... as somehow objectionable.
But here's the thing: I first interacted with the guy in 2014 (as far as I can tell) and wasn't part of the Python Usenet/mailing list culture. I didn't really have that exposure either. And yet it was still extremely obvious to me that the post was calling out injustice and not saying anything that any reasonable person could object to. The central argument is that it's unpleasant to be repeatedly subject to training that assumes you need training to behave yourself and not engage in criminal activity, while the wealthy and powerful get away with those crimes. And people who claim to be on the side of "social justice" take offense to that.
If there's some legitimate reason why a morally good person could object to that post, I never heard it floated the entire time, nor in any of the ensuing discussion anywhere on the Internet (and people have accused me before of being unreasonably interested in that discussion). I have only heard people expect me to take it for granted that this, and similar posts, somehow reflect unreasonable behaviour. And because I legitimately can't think of any charitable way to interpret the argument, I don't speculate.
Tim looks just fine "on that circumstance". It is his interlocutors who look completely unreasonable.
Regardless of who was wrong or right, is it the way you would like to be eulogy written about you? bonoboTP was such a nice person and helped so many person and here is a myriad of example to prove how. All that said, I will remind everyone he had a fight a few years ago with some people he worked with and there were not very nice to him. It is just but a pebble in a long fruitful life, but it is really important I mention it here to remind everyone CoC = bad
I know you're exaggerating but that's not what they were saying. You're jumping to conclusions. Ironically, it was the incorrect and bad faith interpretations that were at the core of the whole saga and how the steering council handled everything.
They are not woke in the first place. The "old white men" keep their corporate positions that they pretend belong to the underprivileged. David Mertz pointed that out and was swiftly disappeared by the Python Gestapo.
> While I've since adopted a tedious posting style to avoid triggering newer people, I haven't really changed. I'm not a grim person, and still find humor (sometimes dark) in almost everything. I just keep all sense of joy bottled up now. "Joy is not professional, supportive, welcoming, or inclusive - unless it's joy at the humiliation of perceived enemies of our new Mandatory Utopia" ;-) [..] > I would like an apology from the PSF, but don't expect one, and don't insist on one. What I demand is that they improve the broken _processes_ that led to this. My case wasn't the first one of trumped-up fantasy charges, and won't be the last
We are talking about a political system which seeks to introduce or apply rules that are obviously unfair on their face, justified by inconsistent theories that constantly make hypocrites of their proponents. It is bizarre and unreasonable to call opposition to this a "political agenda".
As one of the people directly involved in the situation, let me tell you: defending my friend's legacy is part of the mourning. His treatment was clearly unjust on its face and now the people who were responsible and/or supported it or advocated it are trying to blend in and pretend nothing happened, while showing no remorse whatsoever. While I'm sure the benedictions they offer now are sincere, I find it mind-boggling that it seemingly gives them no pause to consider what happened. Especially considering the timing (dying around the second anniversary of the original tension, and this being discovered around the time of his reinstatement).
Tim made an entire separate blog site to plead his case, largely motivated by my own posts[0][1]. His "mea culpa"[2] ceded only a tiny bit of ground, and even that was frankly unreasonable. (In the post[3] where he accepted blame, he was explicitly calling out an oppressive power structure, just apparently not the right one.) Not to mention that he was very clearly being "tone policed" by people acting on behalf of the very movement that popularized the term to try to shield themselves.
The insulting thing is to pretend that any reasonable person could ever have seen any merit in the claims against him after any honest inspection of the evidence (to the extent that evidence was presented: the nature of the claims made it clear what public events were being alluded to, while nothing private was ever asserted to exist).
[0]: https://zahlman.github.io/posts/an-open-letter-to-the-psf-co...
[1]: https://zahlman.github.io/posts/open-letter-psf-coc-wg-adden...
[2]: https://tim-one.github.io/psf/meaculpa
[3]: https://discuss.python.org/t/for-your-consideration-proposed...
You never know when an email is going to be the Last Email. Don't put off reconnecting with old friends.
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
[0]: https://discuss.python.org/t/5778/24