Long time Pythoneer Tim Peters succinctly channels the BDFL's guiding principles for Python's design into 20 aphorisms, only 19 of which have been written down.
Long-time Pythoneer Tim Peters has briefly summarized 20 maxims into 19 sentences of BDFL's basic principles for Python design.
The Zen of Python
Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. 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. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
"Beautiful" rather than "ugly" "Explicit" rather than "implicit" "Simple" rather than "complex", "complex" is better than "hard to understand" "Flat" rather than "nested" "Rattling" rather than "dense" Readability is important There is no special case to break the rules. It seems that "practicality" is superior to "pureness" (consistency). If an error is occurring but you don't know it, it's a different story if it is explicitly specified that "you don't have to notify the error". If you come across an "ambiguous thing", don't lose the temptation to make a "guess" There should be only one straightforward way to do something, though that may be confusing at first glance (if you're Dutch, it's a different story). "Do it now" rather than "do not do" "Do not do" is often better than "do it now" If the explanation is difficult, the implementation is not good. If the explanation is easy, the implementation may be good. Namespaces are a great idea. Let's use this more!
Beauty than ugliness Explicit rather than implicit Simpler than complicated However, it is more complicated than complicated Flatter than nest Sparser than dense More readable Nothing special than breaking the rules Practical rather than genuine Don't tolerate the error Unless it is clearly stated that it will be tolerated Don't speculate on ambiguity There should be only one clear path Unless you're Dutch, it may not be obvious at first ... Do it now rather than not do it I don't do it, but it's often better than doing it now ... If it's difficult to explain, the idea isn't good If it's easy to explain, the idea is good Namespaces are a great idea, use more!
Beautiful is better than ugly. It is better to clarify than to imply. It's better to be plain than complicated. Still, it's better to be complicated than complicated. The nest should be shallow. It's better to have a gap than to be crowded. Easy to read is good. Being special is not a reason to break the rules. However, when it comes to practicality, purity can be lost. Don't hide the error, don't ignore it. However, if it is hidden on purpose, don't miss it. If you come across something ambiguous, don't guess what it means. There must be some good way. There is only one way that is obvious to everyone. The method may be difficult to understand at first glance. It may be easy to understand only for Dutch people. Do it now, rather than not doing it all the time. But it's often better not to do it now than to do it "immediately". If it's hard to explain what the code is, it's a bad implementation. If you can easily explain the content of the code, it's probably a good implementation. Namespaces are a great idea and should be actively used.
https://www.lifewithpython.com/2013/01/pep-20-the-zen-of-python.html https://ct-innovation01.xyz/DL-Freetime/pep-20/ https://www.python.org/dev/peps/pep-0020/ https://qiita.com/IshitaTakeshi/items/e4145921c8dbf7ba57ef
Recommended Posts