$ 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!
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.)
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
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 learned Java in 1996 in college. I was introduced to Python (1.5.2) at a startup in 2000. The startup was probably equally split between Java and Python code. I've essentially used Python almost exclusively since then. It's served me well in my career. I never have cared for Java.
Thank you for explaining the joke that's now old enough to drink, but somehow has eluded me all this time. :-)
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:
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."
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.
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.
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
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.
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 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.
Simple and complex are two sides of the same coin. Both are everywhere in nature. Complication is something else, but how can you describe it? I can think of examples. Bureaucracy comes to mind. Locking and synchronization primitives too. The kind of fragile mechanisms in the Linux kernel that lead to endless CVEs are another. All man-made things!
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.
> 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.
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.
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.
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`.
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.
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 .
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 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.
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.
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.
In the 1990s I was a novice developer, though I considered myself a hotshot because I was better than those around me in college and grad school.
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>
[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'.
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.
Among other places, Tim also wrote a lot on StackOverflow. He’d answer all kinds of questions, both from novices and experts.[0][1]
I like reading his answers. He always seemed to have something interesting to say, and his answers are kind, light-hearted, approachable and insightful.
I had largely moved on from Usenet and mailing lists by the mid 00s when I started using Python in earnest, so I was largely unaware of the people involved even if I would have recognized the names. Tim's participation in Stack Overflow gave me (at least as best I can recall) my first real exposure to him as a person, and resulted in a cherished memory and one of what I like to cite as the feathers in my cap: https://stackoverflow.com/questions/21297887 .
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.
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 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...
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
We are naive when we think, as we all do at times, that humans in our <group> differ from the others - that we 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.
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.
Doesn't take a lot of care to post a one sentence comment. But I get it, it would be preferable to "you people" (to point your phrase back at you) to memory-hole those times.
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.
(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 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.
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 also part of the whole saga but I think mostly how the steering council handled everything.
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.
This is a good time to remind everyone of the shabby way the PSF treated Tim Peters, a bunch of lesser minds and nasty people gossip-attacking a great mind and a lovely chap[0].
"[Tim] took up Python on a lark in its very early days, becoming something like Python’s second real user after Guido.
Guido came to rely on Tim heavily. Tim will demur about this, but as far as I can tell, Tim and Guido were largely partners in the design evolution of very early Python, and before most important features made it in to Python, you could be sure that they had been examined from every angle, shaken, stirred, and thunk about very hard by both of them.
Tim often played the role of gatekeeper and polisher. 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.
[...]
Tim was a Director of the Python Software Foundation from 2001 to 2014, bringing Python across an uncanny valley from a time where it was “interesting but ignorable” to “the planet’s default language” along with a cast of other incredible people. If you use Python, it’s not in small part due to Tim."
Yesterday, out of nowhere I remembered Zen of Python and looked it up to refresh my memory. Prior to that I hadn't known who the author was, so when I saw Tim Peter's name I had a moment of realization that it's the same person who invented Timsort and the same person who was banned from python forums a few years ago for opposing arguing agains bylaw changes.
It feels surreal to learn about his death just the next day. RIP
Timsort is presumptively the best-known thing, but he did quite a lot else for core CPython development. As far as I can tell, most of it actually relates to algorithms for handling large integers and the Decimal data type.
For anyone with more context, could you please help me understand why this wasn't announced earlier? Seems like such a great loss to the community. But, waiting until November to announce the death of a pioneer in July doesn't seem to sit right. Unless there's any historical or cultural context (in which case, I apologize in advance).
The PSF has become a force of ideological machine with zero tolerance to any disagreement. Tim was sadly banned from the very community he helped to build. He wrote about his ban, see https://tim-one.github.io/psf/
There was a "discussion" about some terminology in Python that was considered offensive going on and I remember a tweet from someone (I think it was Guido but I'm likely wrong) saying that many people who argue about these things (referring to politically correct terminology) seem to forget what Python was named after.
The language was named after the British comedy troupe rather than the snake.
It was this. There's no nefarious explanation. It's simply that Tim's real-world life didn't overlap much with his online life. People noticed that he had been quiet for a while, went looking, and found his obituary.
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.
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.
Ugh. As a teen in the aughts interested in computers two things stuck with me. Sitting in his lap and "helping" my dad do SQL modules as he job hunted after the dot com crash, and "discovering" the Zen of Python and Python many years later.
Never really ended up using Python outside one-off scripts and personal stuff but learning the magick of making silicon do work for you and principles for that really stuck with me as I went to high school and beyond.
Not speculating about Tim Peters and why he died, but careers in CS promote a sedentary lifestyle, that might have something to do with it. At the same time, Alan Kay is 86!
good thing you losers harassed him towards the end of his life with your woke bullshit. what a beautiful thanks for all that he did for Python. a little cherry on top from ungrateful, hateful takers instead of makers.
Ah, yes who more fitting to give a eulogy than Guido, who so bravely spoke up when the woke crazies tried to defenestrate (the unfailingly polite, kind and patient) Tim not even 2 years before his death.
As a greybeard (literally) of the industry, I've reached the age where the people who shaped my younger years, and much of the computing world around me, are slowly being piped to /dev/random.
It's sad to hear, but reflecting on the impact Tim made brings some comfort. Most of us will never know how many people our work helped. Tim could at least see some of that, though even Python's reach can only tell part of the story.
Reading the tributes (https://discuss.python.org/t/in-memoriam-tim-peters-1952-202...), what strikes me is how often people mention his patience and humour alongside his technical brilliance. There's something to aspire to there: doing good work, and taking the time to help others do theirs.
The older I get, the more I appreciate what it takes to leave both kinds of legacy.
Quiet lines of code
Still guide the hands of strangers
His kindness lives on
Indeed, as someone with some grey in his beard, it hits harder because these where names I was familiar with when I was young (and now I'm not), I've never really been in the python world but I've used it a fair bit over the years and so I've seen comments from Tim here and there, it seeps into your conscious over time.
There are a handful of names in the tech industry who will hit me particularly hard and among those one who will really make me pause.
They will leave behind work that continues to impact the world but given the choice I'd still have them in it.
In my case none of the work I leave behind is going to mean a real lot outside of the people who paid me for that and I'm old enough that the majority of what I've written over the years is now no longer having any impact (refactored or replaced after years) though I'm aware of one that is still actively supported now that is 17 years old.
Almost everything all of us do in terms of actual work output is transient but we do leave memories, I have a mental list of programmers I've worked with over the years who left a last impact and while none of them afaik had the impact of Tim Peters broadly they did narrowly for me at least.
There's also a brief statement on LWN (https://lwn.net/Articles/1106901/), although it only really links to the announcement. Still good to know that they care.
I'm willing to bet money that the most rabid (scratch that) vocal people who demanded blood, didn't contribute to Python language and Python community 0.0001% of what he did. Just a hunch.
What actually happened (feel free to look it up), is that Tim got into a series of disagreements with people who wrote things like:
'''
Our current board has a majority of people from the Global South or otherwise marginalized groups. That is encouraging and an extremely positive thing. As long as people who are demographically similar to me do not again have a majority, I have the utmost faith in the Board.
As far as I’ve seen, the entire support of this amendment comes from people who look and speak a whole lot like me. People like me should not be trusted.
'''
I think that such people have embarrassed themselves sufficiently over the past few years, and that Tim would not have wanted us to use his obituary to embarrass them further. I say this as a person whose family comes from the Northern hemisphere portion of the Global South.
> "Instead, Python is now a grey, humorless, corporate place. The Steering Council and CoC Working Groups assume they can simply get away with asserting their correctness, crushing any dissent gracelessly, and relying on Python now being too big to fail. They’re probably right. That is a shame. Being now too big to fail is in no small part due to Tim being exactly whom he is within the threads that they derive their accusations from, and he deserves better."
Somehow I missed all the (disgusting) drama back then, but Tim had an entire page dedicated to PSF's woke insanity [1]. Rest in peace.
Which is stored in `this.s` as the following string:
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!
Oh, ROT13!
https://github.com/python/cpython/blob/main/Lib/this.py
...but why? Why is it encrypted and not stored as plaintext?
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.)
Wouldn’t be much of an easter egg if it was too easy to understand <wink>?
Easter eggs are a code smell now, completely unacceptable. I'm sure the fun police will be all in to remove it.
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.
> Oh yeah, I figured that out since the last time.
It's incredible how every single thought you think it's yours was already had a bunch of times.
The PEP explicitly says there are 20 of which only 19 are written down and I can't figure out if that is a joke, a deliberate statement, or both.
And at that moment, shiandow was enlightened. ;)
(https://en.wikipedia.org/wiki/Zen_of_Python has more about the discrepancy.)
Two of the most common bugs in programming is the off-by-one error.
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
More succinctly, you can run this as a module:
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 learned Java in 1996 in college. I was introduced to Python (1.5.2) at a startup in 2000. The startup was probably equally split between Java and Python code. I've essentially used Python almost exclusively since then. It's served me well in my career. I never have cared for Java.
Thank you for explaining the joke that's now old enough to drink, but somehow has eluded me all this time. :-)
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:
https://web.archive.org/web/20211128002836/https://code.acti...
For good reasons, Pythonistas were not appreciative! :)
c.f. what happens when you try `from __future__ import braces`
The call to import this has more than the Python syntax meaning.
I have cited this poem countless times over the years--sometimes ironically. I'm sad.
This is a lot of wisdom, which you can tell comes from years of experience. I would like all llms of the world to have this as their base prompt.
https://www.youtube.com/watch?v=anyhBdt79Cs
Pretty much all of this critique applies squarely to the Zen of Python.
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."
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.
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.
See also, Constraints Liberate and Liberties Constrain
Complex = a problem that's inherently difficult to solve due to its fundamental nature. Time is a great example.
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).
I'll take a stab in this context:
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
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.
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 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.
to complicate = to make more complex
If something is complex, you have to deal with it. But to complicate things is to be avoided.
Simple and complex are two sides of the same coin. Both are everywhere in nature. Complication is something else, but how can you describe it? I can think of examples. Bureaucracy comes to mind. Locking and synchronization primitives too. The kind of fragile mechanisms in the Linux kernel that lead to endless CVEs are another. All man-made things!
> it’s the same word!
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-...
For some reason, this describes Rust to me way better than it describes Python.
> 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.
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.
Let's start off with 'Which Python?'
There will always be a billion way to write the same algorithm in a Turing-complete language. That is not the point.
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.
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.
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`.
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.
And typing wasn't explicit for a long time. Now it is kind of best practice, but you can still produce Python without typecheck metadata.
Practicality beats purity!
Except it mostly just leads to suprising bugs and time wasting, in exchange for saving a small amount of typing
Do you know why it is the way it is?
I took this mantra with me when I learned other languages.
Hard to disagree with any of this. RIP.
It's hard to disagree, since it's very vague and subjective.
Thank you, Tim Peters.
.
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 .
(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.)
Hi I'm the aforementioned Gary Robinson. Very sad to hear of Tim's passing. A really nice guy. And he wrote the following code for the SpamBayes project: https://www.linuxjournal.com/files/linuxjournal.com/linuxjou...
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 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.
Bayes theorem dates back 250 years.
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
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.
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.
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.
One of my favorite Tim Peters comp.lang.python posts has always been this one in the discussion of doctest:
https://groups.google.com/g/comp.lang.python/c/DfzH5Nrt05E/m...
> 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.
Don't forget how he signed that post:
> if-tabs-were-called-hemorrhoids-as-god-intended-people-would-see-them-for-the-bloody-mess-they-are-ly y'rs - tim
In the 1990s I was a novice developer, though I considered myself a hotshot because I was better than those around me in college and grad school.
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'.
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.
RIP Tim
[0]: https://discuss.python.org/t/5778/24
Among other places, Tim also wrote a lot on StackOverflow. He’d answer all kinds of questions, both from novices and experts.[0][1]
I like reading his answers. He always seemed to have something interesting to say, and his answers are kind, light-hearted, approachable and insightful.
[0] https://stackoverflow.com/a/69859068
[1] https://stackoverflow.com/a/19391867
I had largely moved on from Usenet and mailing lists by the mid 00s when I started using Python in earnest, so I was largely unaware of the people involved even if I would have recognized the names. Tim's participation in Stack Overflow gave me (at least as best I can recall) my first real exposure to him as a person, and resulted in a cherished memory and one of what I like to cite as the feathers in my cap: https://stackoverflow.com/questions/21297887 .
He wrote a very detailed answer to a question I had years ago: https://stackoverflow.com/questions/61758735/find-longest-ad...
At the time I didn't realize it was the Tim Peters. Very helpful guy. RIP
My last exchange with Tim was him saying that he wasn't feeling up to having visitors.
You never know when an email is going to be the Last Email. Don't put off reconnecting with old friends.
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.
Nice obituary, would have been cool if Guido had stood up for him when he was witch hunted by Python leadership...
https://chrismcdonough.substack.com/p/the-shameful-defenestr...
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.
I sometimes wonder if people-who-think-of-solving-problems-not-creating-them-defensively should secede from the rest of the Internet.
They can keep the tools & remix new ones with LLMs. The rest of us can hang out in some tiny corner talking civilly.
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 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...
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
We are naive when we think, as we all do at times, that humans in our <group> differ from the others - that we 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.
No, it's just entryism. It's not inevitable. Long march. I was naive once, too.
That isn’t a fair statement to make
How so? Did he stand up for him?
How cowardly that he doesn't even mention that here.
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.
Doesn't take a lot of care to post a one sentence comment. But I get it, it would be preferable to "you people" (to point your phrase back at you) to memory-hole those times.
I don't know.
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)
Python leadership threw him under the bus and now it's all nice obituaries pretending nothing happened.
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.
(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 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.
> 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 also part of the whole saga but I think mostly how the steering council handled everything.
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.
RIP my friend.
This is a good time to remind everyone of the shabby way the PSF treated Tim Peters, a bunch of lesser minds and nasty people gossip-attacking a great mind and a lovely chap[0].
[0] https://lwn.net/Articles/1002340
mcdonc wrote:
"[Tim] took up Python on a lark in its very early days, becoming something like Python’s second real user after Guido.
Guido came to rely on Tim heavily. Tim will demur about this, but as far as I can tell, Tim and Guido were largely partners in the design evolution of very early Python, and before most important features made it in to Python, you could be sure that they had been examined from every angle, shaken, stirred, and thunk about very hard by both of them.
Tim often played the role of gatekeeper and polisher. 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.
[...]
Tim was a Director of the Python Software Foundation from 2001 to 2014, bringing Python across an uncanny valley from a time where it was “interesting but ignorable” to “the planet’s default language” along with a cast of other incredible people. If you use Python, it’s not in small part due to Tim."
Yesterday, out of nowhere I remembered Zen of Python and looked it up to refresh my memory. Prior to that I hadn't known who the author was, so when I saw Tim Peter's name I had a moment of realization that it's the same person who invented Timsort and the same person who was banned from python forums a few years ago for opposing arguing agains bylaw changes.
It feels surreal to learn about his death just the next day. RIP
Timsort is presumptively the best-known thing, but he did quite a lot else for core CPython development. As far as I can tell, most of it actually relates to algorithms for handling large integers and the Decimal data type.
Tim's Blog https://tim-one.github.io/psf/
"Question everything. Love everyone" (from his page)
RIP "Uncle Timmy".
For anyone with more context, could you please help me understand why this wasn't announced earlier? Seems like such a great loss to the community. But, waiting until November to announce the death of a pioneer in July doesn't seem to sit right. Unless there's any historical or cultural context (in which case, I apologize in advance).
The PSF has become a force of ideological machine with zero tolerance to any disagreement. Tim was sadly banned from the very community he helped to build. He wrote about his ban, see https://tim-one.github.io/psf/
There was a "discussion" about some terminology in Python that was considered offensive going on and I remember a tweet from someone (I think it was Guido but I'm likely wrong) saying that many people who argue about these things (referring to politically correct terminology) seem to forget what Python was named after.
The language was named after the British comedy troupe rather than the snake.
I doubt Guido waited with the announcement, it's most likely he and nobody in the community knew before this week.
It was this. There's no nefarious explanation. It's simply that Tim's real-world life didn't overlap much with his online life. People noticed that he had been quiet for a while, went looking, and found his obituary.
Tim's description of dicts always stuck with me by describing the hash table slot states as one of citizen, virgin, or turd[1]. <wink>
1: https://mail.python.org/pipermail/python-list/2000-March/048...
The Tim of Tim Sort, for those that want to identify him quickly.
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.
That was one of the things Oracle sued Google over in that big Android/Java suit right?
It's the Tim of the Zen of Python for me
Thanks, Tim. Your contributions have helped me feed me family over the years. RIP
(I've taught the Zen of Python, doctests, timsort, and more during my career.)
I was honored to work with Tim for a couple of years. He was one of the smartest and funniest people I've ever known. He will be missed.
I learned how to be a person on the internet in large part by watching Tim back in the day. RIP.
Tim (of Timsort) was a long time python contributor (aka 90s), and a foundation of its early community (>>> import this). Rip.
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.
The world is a bit dimmer for your absence. We miss you.
Ugh. As a teen in the aughts interested in computers two things stuck with me. Sitting in his lap and "helping" my dad do SQL modules as he job hunted after the dot com crash, and "discovering" the Zen of Python and Python many years later.
Never really ended up using Python outside one-off scripts and personal stuff but learning the magick of making silicon do work for you and principles for that really stuck with me as I went to high school and beyond.
RIP :'(
He once answered my noob stackoverflow question. I had a fanboy moment after reading the about section of his profile: https://stackoverflow.com/users/2705542/tim-peters
He'll be sorely missed by everyone who has read the Zen of Python (but not limited to it ofc).
Such a moving piece.
Condolences.
The first thing I was taught by my first boss was import this.
Lived most of my life since by those principles where practically applicable.
Every time `1 + 2.5` just works in Python, that's Tim. RIP
Genuine question - why do you think many seminal figures in CS dying at a relatively young age?
Not speculating about Tim Peters and why he died, but careers in CS promote a sedentary lifestyle, that might have something to do with it. At the same time, Alan Kay is 86!
I quoted im earlier today in a commit message at work. Not knowing him at all, this news is a bit of a shock.
RIP. I didn't know him IRL, but I remember him fondly from the Python Usenet group and Python bug tracker discussions.
The Steering Council bureaucrats must be very happy that he cannot "post too many mails" or "use the wrong language" on the mailing lists any longer.
Your corporate sinecure "custom Python distributions" are secure now!
I miss arguing with Perl… back in the day I wrote a full http proxy in Perl that rewrote and compressed http requests. Fun times.
Legendary contributor.
Thinking that the Python software foundation decided to ban this person for frivolous reasons is both laughable and sad.
https://lunduke.locals.com/post/5985667/python-bans-prominen...
As a programmer who used Python, I'm in debt to him.
good thing you losers harassed him towards the end of his life with your woke bullshit. what a beautiful thanks for all that he did for Python. a little cherry on top from ungrateful, hateful takers instead of makers.
Ah, yes who more fitting to give a eulogy than Guido, who so bravely spoke up when the woke crazies tried to defenestrate (the unfailingly polite, kind and patient) Tim not even 2 years before his death.
Tim? The Tim (Timsort) Peters?
I learned about Timsort and used it in a class as a student long ago. RIP.
May his memory be a blessing
https://en.wikipedia.org/wiki/Tim_Peters_(software_engineer)
https://en.wikipedia.org/wiki/Timsort
If someone has a great photo of Tim they'd be willing to license to Wikimedia for his page, it would be appreciated.
https://commons.wikimedia.org/wiki/Commons:Email_templates#E...
May he rest in peace, I just learned about Timsort!
Very, very sad news. RIP Tim Peters.
RIP.
o7
As a greybeard (literally) of the industry, I've reached the age where the people who shaped my younger years, and much of the computing world around me, are slowly being piped to /dev/random.
It's sad to hear, but reflecting on the impact Tim made brings some comfort. Most of us will never know how many people our work helped. Tim could at least see some of that, though even Python's reach can only tell part of the story.
Reading the tributes (https://discuss.python.org/t/in-memoriam-tim-peters-1952-202...), what strikes me is how often people mention his patience and humour alongside his technical brilliance. There's something to aspire to there: doing good work, and taking the time to help others do theirs.
The older I get, the more I appreciate what it takes to leave both kinds of legacy.
Quiet lines of code Still guide the hands of strangers His kindness lives on
Rest well, Tim.
Indeed, as someone with some grey in his beard, it hits harder because these where names I was familiar with when I was young (and now I'm not), I've never really been in the python world but I've used it a fair bit over the years and so I've seen comments from Tim here and there, it seeps into your conscious over time.
There are a handful of names in the tech industry who will hit me particularly hard and among those one who will really make me pause.
They will leave behind work that continues to impact the world but given the choice I'd still have them in it.
In my case none of the work I leave behind is going to mean a real lot outside of the people who paid me for that and I'm old enough that the majority of what I've written over the years is now no longer having any impact (refactored or replaced after years) though I'm aware of one that is still actively supported now that is 17 years old.
Almost everything all of us do in terms of actual work output is transient but we do leave memories, I have a mental list of programmers I've worked with over the years who left a last impact and while none of them afaik had the impact of Tim Peters broadly they did narrowly for me at least.
> slowly being piped to /dev/random.
Some are gently deallocated. Others are garbage-collected.
Tim was reference counted surely?
I posted my thoughts in a parallel thread, at https://news.ycombinator.com/item?id=50451689 .
I focus on how I learned to be a better software developer from him, in both writing better code and supporting others.
(We've since merged that thread hither.)
https://news.ycombinator.com/item?id=50450488 links to GvR's announcment on discuss.python.org .
There's also a brief statement on LWN (https://lwn.net/Articles/1106901/), although it only really links to the announcement. Still good to know that they care.
A black bar is appropriate for this news.
Black bar, anyone?
Sounds like he was living quietly out of the spotlight, or his family kept news of his death private. He died back in July.
Agreed. As it was for Fredrik Lundh (aka "the effbot") a few years ago.
[flagged]
banned for insignificant banality by peoples with misplaced hyper sensitivity. It's a black mark on the code of conduct not on Tim Peter !
I'm willing to bet money that the most rabid (scratch that) vocal people who demanded blood, didn't contribute to Python language and Python community 0.0001% of what he did. Just a hunch.
What actually happened (feel free to look it up), is that Tim got into a series of disagreements with people who wrote things like:
''' Our current board has a majority of people from the Global South or otherwise marginalized groups. That is encouraging and an extremely positive thing. As long as people who are demographically similar to me do not again have a majority, I have the utmost faith in the Board.
As far as I’ve seen, the entire support of this amendment comes from people who look and speak a whole lot like me. People like me should not be trusted. '''
I think that such people have embarrassed themselves sufficiently over the past few years, and that Tim would not have wanted us to use his obituary to embarrass them further. I say this as a person whose family comes from the Northern hemisphere portion of the Global South.
Obviously a great man, but that was no defense when the intolerant leftists came for him.
https://discuss.python.org/t/three-month-suspension-for-a-co...
From "The Shameful Defenestration of Tim" [0]:
> "Instead, Python is now a grey, humorless, corporate place. The Steering Council and CoC Working Groups assume they can simply get away with asserting their correctness, crushing any dissent gracelessly, and relying on Python now being too big to fail. They’re probably right. That is a shame. Being now too big to fail is in no small part due to Tim being exactly whom he is within the threads that they derive their accusations from, and he deserves better."
Somehow I missed all the (disgusting) drama back then, but Tim had an entire page dedicated to PSF's woke insanity [1]. Rest in peace.
[0] https://chrismcdonough.substack.com/p/the-shameful-defenestr...
[1] https://tim-one.github.io/psf/
lol, that's a badge of fucking honor right there!