upvote
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.
reply
Let's start off with 'Which Python?'
reply
There will always be a billion way to write the same algorithm in a Turing-complete language. That is not the point.
reply
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.
reply
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".
reply
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.

reply
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`.

reply
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.

reply
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.

reply
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.
reply
Practicality beats purity!
reply
Except it mostly just leads to suprising bugs and time wasting, in exchange for saving a small amount of typing
reply
Do you know why it is the way it is?
reply