The contention here is that Python v3, as it was released, does not encode the spirit of Python3k*. Python3 was fine for script kids and bankers, but not good enough to be called PythonThreeThousand. For true Python3k, it needs to get its Zen back.

''Python has JumpedTheShark''
* That's funny, but Python was doing great at v2.6 and didn't need to "jump the shark", so it doesn't seem to explain it.  The problem was that the community silently forked when the type/class unification happened, because it spelled a departure from the scientific computing bias of keeping a connection to the machine.

Review:

'''The Zen of Python:'''

* Beautiful is better than ugly.

This is good.

* Explicit is better than implicit.

Good, but PythonLanguage relies on implicitness for typing. So one must separate these two and be clear. Let's rewrite as:

''Code should be explicit, *types* implicit.''

* Simple is better than complex.

Yes. Is this instructional?

* Complex is better than complicated.

These terms are now muddied. Let's say:

''Complex is better than SpaghettiCode or a tangled mess''.

* Flat is better than nested.

No. This was only true before the proposed revamping of the ObjectModel for PythonThreeThousand when no one knew how to nest complex trees properly. If you root in the tree in the '''***machine***''' the way is clear: a DataEcosystem managed by the interpreter and user/programmer. Python followed a dead-end trying to root it all in a GodObject (or rather GodClass).

** ''How is that a dead-end?''

** Because no one has the foresight to make a generic object that will be able to do what every possible class needs at ''every'' level.

** ''A base class for all objects normally has no functionality, beyond that which the language requires of every object.  That functionality is invariably an aspect of the language itself, so it is trivially changed with new versions of the language implementation.''

* Sparse is better than dense.

Probably, '''functional separation''' is what you're aiming for with removing redundancies for things/code used more than twice.

* Readability counts.

Yes, aim for SelfDocumentingCode, DocTest''''''s.

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

Correct.

* Although practicality beats purity.

In the near-term. With a true PythonThreeThousand rooted in a UnifiedDataModel, these special cases will no longer be needed.

* Errors should never pass silently.
* Unless explicitly silenced.

Good.

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

Fine.

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

One of the most powerful rules here.

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

Yes, and here we have the cross-roads of PythonThreeThousand. Never is better, until you're ready to ''get it right''.

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

Right. See also: MasterOfTheMachine.

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

Yes.  At least it's easier to critique.

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

Yes, but how shall we do it?  A tree of attributes off of a central trunk? 

----
(*) Specifically, it has to do with how it conceived of (and coded) the "bytes" type.
----
In short, Python Rational's had way more Zen than Decimals.  And str/bytes has way more purity and truth than Unicode strings.

See more at PythonThreeThousand.
----
See also WhatIsTheDifferenceBetweenPythonTwoAndPythonThree
----
CategoryPython