No. I definitely want to work in a utopia, but that's not what Python is, and the Zen is kind of a pretentious idea. The fact that it's a PEP and treated like an objective guide is a bit absurd don't you think?

Anyway, I realize people feel very strongly about subjective opinions, so I'll just lay out where the Zen doesn't work out in my opinion. I'm not going to belabor the point; these are just small observations off the top of my head, and without a lot of contextual detail. I'm well aware my opinion can be "refuted" and I am aware of the answers to my own questions, but I challenge you to see past that to identify where/when/how/why the Zen doesn't really apply, rather than focusing on my opinion alone.

Beautiful is better than ugly.

Too subjective and hand-wavy. We all want "beautiful" code, but what that is changes from person to person and team to team. Personally I prefer C-like languages, and I don't like Python's significant whitespace, so this part of the Zen already fails for me.

Explicit is better than implicit.

Sure, but not always, and this can interfere with "beautiful code."

Why can we do class Foo: instead of class Foo(object):?

Why are all class members public, and we only have a convention to "explicitly define" that a member is private?

Why be explicit with a complex type annotation if your static typing tools will infer them?

Simple is better than complex.

Yes, generally, but Python certainly enables complexity and makes some things more confusing than they need to be.

The existence of both __getattr__ and __getattribute__ make this concept more complex.

The messy static type system is way overcomplicated (I'm genuinely surprised by how bad some of it is). Callable[[T1,T2,...], R1]; Tuple[T1, T2], Union[T1, T2]? 3.11 introduced NotRequired[T], a "type" to indicate whether assignment to a member is required. Yeesh!

The excessive use of *args and **kwargs everywhere in Python and external libraries. This also falls under "explicit is better than implicit."

Complex is better than complicated.

Uh, okay. General platitude.

Flat is better than nested.

Python uses significant whitespace to define scope. Sometimes we can't flatten things by the nature of how to write Python.

Sparse is better than dense.

Another platitude, but it also kind of conflicts with "explicit is better than implicit."

Readability counts.

That's what the entire PEP is about ...

Special cases aren't special enough to break the rules.

This can certainly be true, but where's the nuance? Sometimes you need to write code for different operating systems (look at pathlib, for example). Sometimes there are special cases that change how you need to style your code.

Although practicality beats purity.

Another platitude - Plus, in a succinct document like this, don't make a point and then refute it immediately after. Just don't include either point, or make the points more specific so they mean something and don't cancel each other out.

Errors should never pass silently.

Sure, but we don't always need to throw exceptions either, and we don't always need to crash, and we don't always need to log.

Unless explicitly silenced.

Okay - again, canceling the previous point. And this point-blank states that this is okay:

try:
    something_that_throws()
except:
    # let's even make it explicit rather
    # than implicit by commenting
    # why this is ignored
    pass

In the face of ambiguity, refuse the temptation to guess.

Guess what, exactly? The reads more like a general suggestion for how to collaborate with people.

There should be one-- and preferably only one --obvious way to do it.

Oh man. Do I really need to write about this one? It's by far the least truthful aspect of the Zen, and something that is brought up frequently. I mentioned one above (how to create a class).

There's also the different forms of catching exceptions. except, except Exception, and except Exception as e.

List/dictionary comprehensions and loops.

Lambdas and methods.

Type hints like Union[T1, T2] and T1 | T2.

Tuples: (1,2) and 1,2

This one can cause failures: assert condition, msg and assert (condition, msg) The latter is an error, but Python's syntax doesn't make this obvious.

x = 1.0 and x = float(1.0).

The allowance of different levels of indentation, e.g., you can use 1 space in an area, and 20 spaces deeper inside that same nesting.

os.path and pathlib.

and on and on.

Although that way may not be obvious at first unless you're Dutch.

What does this even mean? If I have to search outside of the [intended to be] simple and succinct PEP to figure out what it's saying, then the PEP is too vague or open to interpretation.

Now is better than never.

Definitely not always true, and a guide on writing Python should not dictate how you deliver software.

Although never is often better than right now.

Once again, another canceled point. These could all be rolled up into just "Be practical."

Also - "never?" Tell that to the people using your software.

If the implementation is hard to explain, it's a bad idea.

Right, let's not use the fast-inverse square algorithm. Let's not adhere to correctly delivering TCP packets. Let's never use monorepos, or services, or infrastructure deployments, etc. etc. Sometimes things are complex.

If the implementation is easy to explain, it may be a good idea.

Another platitude.

Namespaces are one honking great idea -- let's do more of those!

Okay ... weird to add to this document.