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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/2NAEY7NMB45V2C2DGXBGMQIY2U55ZQNB/
Code of Conduct: http://python.org/psf/codeofconduct/
