很多人都写过交互式的代码,但都没有系统的写过。可能有因为写脚本或程序更实在。但写程序是要有基本功的。这个基本功没打好,是难以写出程序的,特别的原创的。我以为写交互式的片段代码,可能是打基础的一个重要方法。
还有一个问题的是:在现今的环境下,在交互式下写出来的东西,需要重复输入,不象写脚本。一次输入就行了。分亨也是一个问题。
如今这些问题不再是问题,python交互式集成环境中你可以象写脚本一样写交互式的代码。不再需要重复输入交互式的代码,可以自动的演示你的代码。可以把代码置方便地subversion下。可以把你写的交互式代码置于一个或多个文件中,可以进行系统的分类。最重要的是:可以最高效的分亨:别人写好的交互式代码可以立即进行验证。总之:跟写脚本的区别的越来越小。
看一看一些图片吧:




到底传说中的Python 3000是什么样子的,我们拭目以待。
尽管blog是很私人化的地方,如果涉及了公共的东西,则很难独善其身。
看到一些热心人,用python创造了一些学习python的站点。其中我表达了自己的一些看法,下面就是我的发言。
也许,编程是难事。看到大家都在求同。可能是一些试验性的东西。
豆瓣之所以是豆瓣,就在于它不同于其它的网站。它有自己的鲜明特色。
老实说,我做不出上面的东西来。也许我不该说这样的话.....。
不过,这种话,不受人待见。
在mailing list中有人用论坛来提供python学习的场所,我说了以下的话。
在blog当道的今天,论坛的局限性越来越明显。理由很明显:
从长远来看:谁都不会无原则地贡献自己所写的内容。
不过,只要肯坚持下去,未尝不是一个学习python的去处的选择。
可能是我有所期待,所以才会如此。或是做梦是最容易的一件事,我不费力气就说了上面的话。
好了,不说了。
在python在交互式下输入:
import this
The Zen of Python, by Tim Peters
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!
python之禅。
Namespaces are one honking great idea — let’s do more of those!这是最后一句。
其实还有一句:”Correctness and clarity before speed.” python缺的就是速度。ygao想这句没正式加上,是有这个原因吧。
接着上面的话题:很多人都忽视了这最后一句,名字空间是一个非同一般的理念–让我们反复实践这一理念。如果说“吾道以一贯之”,那么名字空间就是python的这个一。其它语言也有名字空间,不过是静态的。 python的名字空间在运行时都还存在。“Each object is a namespace in its own right”Guido在”Why I Invented Python”写道。任何东西都在名字空间中。模块或类或类实例等。不仅如此,名字空间还可以动态改变,动态地创造。什么mixin和metacalss技术无不跟名字空间有关。
动态类型其实就是对象类型,不过就是名字绑定到对象的一个过程。在python名字不算什么,唯一重要的是它“指向”一个有类型的对象,一种关系。它跟数据类型不一样,数据的类型决定其操作。对象只要有了类型就已经有方法了。有了对象就有方法,动态产生的动象,一样有方法。类型检查是没有什么意义的。也就是所谓duck-typing, 利用对象的属性和方法而不是类型进行编程。只有有了python的思维,才能把这种编程进行下去。
>>> class X:
… def x(self):
… print b
… #b=2
…
>>> b=1
>>> X().x()
1
>>>
>>> class X:
… def x(self):
… print b
… b=2
…
>>> b=1
>>> X().x()
Traceback (most recent call last):
File line 1, in ?
File line 3, in x
UnboundLocalError: local variable ‘b’ referenced before assignment
有人用下面的话来解释:Of course the language spec, explains this phenomenon:“If a name binding operation occurs anywhere within a code block, all uses of the name within the block are treated as references to the current block. This can lead to errors when a name is used within a block before it is bound. This rule is subtle. Python lacks declarations and allows name binding operations to occur anywhere within a code block. The local variables of a code block can be determined by scanning the entire text of the block for name binding operations.”
(Python lacks declarations ,这一句话,与我的思路不一致,暂且存疑)
可以看出,动态的名字空间查找过程。名字是在名字空间中,名字空间有名字。在某种程度上就是一个东西。
以前的管理员都是静态的,需要被任命。这对于严肃的组织
很必要。但这也很死板。而且很受制于某个超级管理员,深深地打下其烙印。典型的现在的论坛就是这样。大多数总是问一些翻来覆去的问题。因为发问的过程没有任何的代价,也没有任何的益处。
如果管理是自组织的。首先按提交被通过的次数自动升级为具有一定的权力。随后再次提升。通过提交而来可以获得另处的收益。谁都会注重提交的质量。没有谁会一如既往无收益坚持提交。只有提交的行为本身就是一种益处。大家就可以注重这种行为。一个人的行为得以检点,对整个社区来讲,所有人的行为都可能提高。社区就激发了所有人的力量。这才是社区的真正意义。