Steven D'Aprano writes:
Unfortunately, and with the greatest respect to Tim Peters, in practice that's not how it is used, *particularly* the "One Way" kaon, which is almost invariably used as a thought-terminating cliche.
You've done this rant before. It wasn't persuasive then. It's not persuasive now.
3. Of all the koans in the Zen, the "One Way" koan is probably intended the most to be an ironic joke, not taken too seriously.
Conceded that there's a certain amount of irony there, and the Zen as a whole can be indeed be taken too seriously. But I rather doubt Tim was joking. Parsimony is always a value to be considered, and various aspects of "obvious" are clearly important to Pythonic language design. The problem is that the core argument, here as always, is
The cost here is tiny. This thread alone has probably exceeded by a factor of 100 the cost of implementing the change.
The first sentence is false. What is true is that the cost of implementing the change is only a tiny part of the cost of the change. The largest part of the cost is the language bloat incurred by lowering the bar to the level of trivial changes that benefit someone enough to write the code, document it, commit it, and push it. Those costs are incurred by all the reviewers reviewing trivial changes and prodding implementers to make them readable and PEP 8 conformant, and document them properly, by everyone reading bloated documentation, and by all the maintainers maintaining bloated code, as well as the other implementations that now need to ensure that *two* idioms (str.join and StringIO.__iadd__) are implemented efficiently. (This isn't hard, if StringIO.__iadd__ is efficient, but what if it isn't?) You may have a point that the bar should be lower than it is now, but the bar you propose here (and have proposed repeatedly in the past) is naive and dangerous. That way lies Emacs (which I love to death, but Emacs Lisp is the historic antithesis of a disciplined, well-designed language).
Instead the Python community treats [TOOWTDI] as the most serious of all.
C'mon, Steve, this is obviously not true. I would not be surprised if it's the most cited koan on Python Ideas, but that's because of the large number of trivial (and often bad) ideas proposed for addition to Python, then defended in (moderately) long threads on the grounds that "it's only three lines". Trivial stuff that clears the existing bar gets added despite the koan, and not just because of your long-running campaign against it. Other koans are taken much more seriously. We joke about "bike- shedding", but it's recognized as necessary because "readability counts". Features that sound attractive in the abstract (tuple arguments to removeprefix is a recent example) are withdrawn because "simple is better than complex", and the feature couldn't adduce enough use cases to invoke "although practicality beats purity". Some PEPs languish for literally years because of "In the face of ambiguity, refuse the temptation to guess" or "Although never is often better than *right* now". And both the str.join idiom and all comprehensions are (more or less superficially, I admit) instances of "Flat is better than nested."
with only a *preference* for one way, not a hard rule. And given that Tim wrote it as a joke, having the koan intentionally go against its own advice, I think we should treat that preference as pretty low.
I think you underestimate just how recursively deep Tim's sense of humor is.
The koan isn't satisfied [by str.join], there is One Way but it isn't Obvious.
You forgot that the project was led by Dutchmen, and it was obvious enough to them: Although that way may not be obvious at first unless you're Dutch. Obvious does not only mean "easily discoverable"; it may also mean "unforgettable once seen". I would not have discovered str.join by myself for years, but it was unforgettably correct as soon as I saw it, despite the odd syntax. Ex ante, not obvious to me. Ex post, forehead-flattening levels of "how did I miss that?!" obvious.
Surely the fact that the wrapper is "trivial" should count as a point in its favour, not against it?
Not obvious, as you concede (taken out of context, but I don't think unfairly):
Nevertheless, you do make a good point. It may be that StringIO is not the right place for this. That can be debated without dismissing the entire idea.
If you want the builder to be at all discoverable, it needs to be attached to str, or at least to something more obvious than io, maybe string. But the *trivial* wrapper obviously belongs to io. Making it discoverable is complicated. If you have to import io into string, or worse builtins, it's not trivial any more IMO YMMV. The costs thus mount. Not all that much, but this is just the implementer's side, which is rarely all that expensive for well- defined features. TOOWTDI should bring up a grin when you notice the usage of the dashes, but it's not just a joke. Regards, Steve