Python's Design Philosophy
来源:互联网 发布:js length叹号 编辑:程序博客网 时间:2024/04/29 16:46
Later blog entries will dive into the gory details of Python's history.However, before I do that, I would like to elaborate on thephilosophical guidelines that helped me make decisions while designingand implementing Python.
Firstof all, Python was originally conceived as a one-person “skunkworks”project – there was no official budget, and I wanted results quickly,in part so that I could convince management to support the project (inwhich I was fairly successful). This led to a number of timesavingrules:
Although Iwill discuss more of ABC's influence on Python a little later, I’d liketo mention one readability rule specifically: punctuation charactersshould be used conservatively, in line with their common use in writtenEnglish or high-school algebra. Exceptions are made when a particularnotation is a long-standing tradition in programming languages, such as“x*y” for multiplication, “a[i]” for array subscription, or “x.foo” forattribute selection, but Python does not use “$” to indicate variables,nor “!” to indicate operations with side effects.
Tim Peters, along time Python user who eventually became its most prolific andtenacious core developer, attempted to capture my unstated designprinciples in what he calls the “Zen of Python.” I quote it here in its entirety:
Firstof all, Python was originally conceived as a one-person “skunkworks”project – there was no official budget, and I wanted results quickly,in part so that I could convince management to support the project (inwhich I was fairly successful). This led to a number of timesavingrules:
- Borrow ideas from elsewhere whenever it makes sense.
- “Things should be as simple as possible, but no simpler.” (Einstein)
- Do one thing well (The "UNIX philosophy").
- Don’t fret too much about performance--plan to optimize later when needed.
- Don’t fight the environment and go with the flow.
- Don’t try for perfection because “good enough” is often just that.
- (Hence) it’s okay to cut corners sometimes, especially if you can do it right later.
- The Python implementation should not be tied to a particular platform.It’s okay if some functionality is not always available, but the coreshould work everywhere.
- Don’t bother users with detailsthat the machine can handle (I didn’t always follow this rule and someof the of the disastrous consequences are described in later sections).
- Support and encourage platform-independent user code, but don’t cut offaccess to platform capabilities or properties (This is in sharpcontrast to Java.)
- A large complex system should havemultiple levels of extensibility. This maximizes the opportunities forusers, sophisticated or not, to help themselves.
- Errorsshould not be fatal. That is, user code should be able to recover fromerror conditions as long as the virtual machine is still functional.
- At the same time, errors should not pass silently (These last two itemsnaturally led to the decision to use exceptions throughout theimplementation.)
- A bug in the user’s Python code shouldnot be allowed to lead to undefined behavior of the Python interpreter;a core dump is never the user’s fault.
Although Iwill discuss more of ABC's influence on Python a little later, I’d liketo mention one readability rule specifically: punctuation charactersshould be used conservatively, in line with their common use in writtenEnglish or high-school algebra. Exceptions are made when a particularnotation is a long-standing tradition in programming languages, such as“x*y” for multiplication, “a[i]” for array subscription, or “x.foo” forattribute selection, but Python does not use “$” to indicate variables,nor “!” to indicate operations with side effects.
Tim Peters, along time Python user who eventually became its most prolific andtenacious core developer, attempted to capture my unstated designprinciples in what he calls the “Zen of Python.” I quote it here in its entirety:
- 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!
- TheABC group strived for perfection. For example, they used tree-baseddata structure algorithms that were proven to be optimal forasymptotically large collections (but were not so great for smallcollections).
- The ABC group wanted to isolate the user, ascompletely as possible, from the “big, bad world of computers” outthere. Not only should there be no limit on the range of numbers, thelength of strings, or the size of collections (other than the totalmemory available), but users should also not be required to deal withfiles, disks, “saving”, or other programs. ABC should be the only toolthey ever needed. This desire also caused the ABC group to create acomplete integrated editing environment, unique to ABC (There was anescape possible from ABC’s environment, for sure, but it was mostly anafterthought, and not accessible directly from the language.)
- The ABC group assumed that the users had no prior computer experience(or were willing to forget it). Thus, alternative terminology wasintroduced that was considered more “newbie-friendly” than standardprogramming terms. For example, procedures were called “how-tos” andvariables “locations”.
- The ABC group designed ABC withoutan evolutionary path in mind, and without expecting user participationin the design of the language. ABC was created as a closed system, asflawless as its designers could make it. Users were not encouraged to“look under the hood”. Although there was talk of opening up parts ofthe implementation to advanced users in later stages of the project,this was never realized.
- Python's Design Philosophy
- Love’s Philosophy
- <The Design Philosophy of the DARPA Internet Protocols>读后感
- 简译The Design Philosophy of the DARPA Internet Protocols
- 【Agni-s Philosophy】使用的图形技术解说(后篇)Volume渲染和粒子处理
- UNIX Philosophy
- Unix Philosophy
- Today 's task ----xml design
- Qbo’s concept and design
- Design Patterns in Python
- [Python]Function Design Receipe
- Python Design Patterns
- python filter design
- the UNIX Philosophy
- UNIX philosophy(ZT)
- The UNIX Philosophy
- The Unix Philosophy
- The Philosophy of Scrum
- 千万级分页高效存储过程
- rpmdb: Program version 4.2 doesn’t match environment version
- WINDOWS下的低级音频函数介绍
- 历数CSS缩写的一些好处
- 利用HOOK拦截封包原理
- Python's Design Philosophy
- MFC和模块状态
- Introduction and Overview
- 倒排索引
- 执行iframe中的javascript方法
- 美客机水面迫降,乘客冷静撤离的感触
- 杨天行:信息技术标准化对信息化建设的作用
- 通过jmx监控jboss数据库连接池
- rpm安装软件包的依赖问题