Tim Peters has died (discuss.python.org)
w-m a day ago
$ 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!Waterluvian 20 hours ago
tclancy 15 hours ago
vasco 7 hours ago
It's incredible how every single thought you think it's yours was already had a bunch of times.
svilen_dobrev 20 hours ago
.
gavmor 20 hours ago
glerk 19 hours ago
userbinator 8 hours ago
bitter_michael 19 hours ago
shiandow 19 hours ago
leoc 19 hours ago
(https://en.wikipedia.org/wiki/Zen_of_Python has more about the discrepancy.)
rbanffy 14 hours ago
flykespice 19 hours ago
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.
bigstrat2003 18 hours ago
michaeldh 18 hours ago
logophobia 17 hours ago
loeg 18 hours ago
zestyping 14 hours ago
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.
tacitusarc 13 hours ago
I am not sure if that perspective aligns with yours.
zephen 8 hours ago
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.
driggs 7 hours ago
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`.
benji-york 13 hours ago
buster 18 hours ago
throwaway5752 16 hours ago
bazoom42 4 hours ago
jacquesm 3 hours ago
Buttons840 18 hours ago
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!
darkwater 17 hours ago
FergusArgyll 10 hours ago
anhner 5 hours ago
notpushkin 3 hours ago
Suzuran an hour ago
coffeemug 17 hours ago
collingreen 16 hours ago
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
mmooss 14 hours ago
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-...
kstrauser 14 hours ago
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.
tacitusarc 13 hours ago
caned 14 hours ago
jacobolus 10 hours ago
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.
schrodinger 8 hours ago
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).
noufalibrahim 7 hours ago
MForster 7 hours ago
If something is complex, you have to deal with it. But to complicate things is to be avoided.
js2 17 hours ago
$ python -m this # -mthis works toonine_k 10 hours ago
driggs 7 hours ago
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."
wk_end 6 hours ago
js2 an hour ago
Thank you for explaining the joke that's now old enough to drink, but somehow has eluded me all this time. :-)
davidja 16 hours ago
pwdisswordfishq 7 hours ago
Pretty much all of this critique applies squarely to the Zen of Python.
moron4hire 3 hours ago
bossyTeacher 14 hours ago
ycombinatrix 2 hours ago
leoc 21 hours ago
(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.)
curiousObject 19 hours ago
nly 5 hours ago
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
garyrob 17 hours ago
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.
jeremyjh 13 hours ago
lumpa a day ago
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.
pdonis 20 hours ago
https://groups.google.com/g/comp.lang.python/c/DfzH5Nrt05E/m...
apetresc 20 hours ago
pdonis 16 hours ago
> if-tabs-were-called-hemorrhoids-as-god-intended-people-would-see-them-for-the-bloody-mess-they-are-ly y'rs - tim
dalke a day ago
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'.
ofek 19 hours ago
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
lukasgelbmann 18 hours ago
I like reading his answers. He always seemed to have something interesting to say, and his answers are kind, light-hearted, approachable and insightful.
zahlman 15 hours ago
bjourne 11 hours ago
At the time I didn't realize it was the Tim Peters. Very helpful guy. RIP
linsomniac 20 hours ago
You never know when an email is going to be the Last Email. Don't put off reconnecting with old friends.
zahlman 15 hours ago
linsomniac a day ago
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.
bonoboTP 20 hours ago
polotics 19 hours ago
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.
Postosuchus 16 hours ago
mmooss 13 hours ago
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.
bonoboTP 11 hours ago
corroclaro 16 hours ago
They can keep the tools & remix new ones with LLMs. The rest of us can hang out in some tiny corner talking civilly.
hn_throwaway_99 8 hours ago
vintermann an hour ago
blast 8 hours ago
zaphirplane 5 hours ago
bonoboTP 3 hours ago
staz 5 hours ago
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.
bonoboTP 3 hours ago
cauch an hour ago
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)
bonoboTP an hour ago
staz an hour ago
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
kalaksi an hour ago
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.
bonoboTP an hour ago
philipallstar 5 hours ago
heresie-dabord 15 hours ago
"[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."
asalahli 19 hours ago
It feels surreal to learn about his death just the next day. RIP
zahlman 14 hours ago
rdtsc 19 hours ago
"Question everything. Love everyone" (from his page)
RIP "Uncle Timmy".
neya 9 hours ago
meitham 8 hours ago
noufalibrahim 7 hours ago
The language was named after the British comedy troupe rather than the snake.
Kwpolska 5 hours ago
nedbat 25 minutes ago
grep_it 20 hours ago
1: https://mail.python.org/pipermail/python-list/2000-March/048...
Copenjin a day ago
yowlingcat 20 hours ago
antod 17 hours ago
TZubiri 17 hours ago
__mharrison__ 21 hours ago
(I've taught the Zen of Python, doctests, timsort, and more during my career.)
benji-york 13 hours ago
kgcgfva 19 hours ago
kapilvt a day ago
themanmaran 20 hours ago
hanselot an hour ago
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.
dyoo1979 18 hours ago
benjiwdubs 7 hours ago
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 :'(
ayush--s 8 hours ago
He'll be sorely missed by everyone who has read the Zen of Python (but not limited to it ofc).