2006年05月14日

我用过wing,komodo,都很不错。当然,我更喜欢wing。如果要从开源的角度选一IDE,我要说是boa。很有架构气势。有示范及原型的作用。spe也许更流行。在很多方面也很象boa,在易用性上某些方面强过boa,但不易于扩展。而且把spe的某些功能增加到boa不是难事。主要的是boa功能强大可以与wing、komodo一比。这对于我选择各种开源的IDE来说可能是最重要的一点。

2006年05月06日

我自己增强pycrust的版本在阅读.py的文件方面太弱,我就想整合进boa、spe中。因为它们自带的


shell功能太弱。boa给了shell一个重视,我看了一下,改了两三行代码。居然能成功。突然想到,


能被别的软件利用和能利用别的软件扩展功能一样重要。我增强后的pycrust就具有了这个能力。


2006年04月20日

很多人都写过交互式的代码,但都没有系统的写过。可能有因为写脚本或程序更实在。但写程序是要有基本功的。这个基本功没打好,是难以写出程序的,特别的原创的。我以为写交互式的片段代码,可能是打基础的一个重要方法。


还有一个问题的是:在现今的环境下,在交互式下写出来的东西,需要重复输入,不象写脚本。一次输入就行了。分亨也是一个问题。


如今这些问题不再是问题,python交互式集成环境中你可以象写脚本一样写交互式的代码。不再需要重复输入交互式的代码,可以自动的演示你的代码。可以把代码置方便地subversion下。可以把你写的交互式代码置于一个或多个文件中,可以进行系统的分类。最重要的是:可以最高效的分亨:别人写好的交互式代码可以立即进行验证。总之:跟写脚本的区别的越来越小。


看一看一些图片吧:



2006年04月06日

到底传说中的Python 3000是什么样子的,我们拭目以待。


 

尽管blog是很私人化的地方,如果涉及了公共的东西,则很难独善其身。

看到一些热心人,用python创造了一些学习python的站点。其中我表达了自己的一些看法,下面就是我的发言。

也许,编程是难事。看到大家都在求同。可能是一些试验性的东西。
豆瓣之所以是豆瓣,就在于它不同于其它的网站。它有自己的鲜明特色
 
老实说,我做不出上面的东西来。也许我不该说这样的话.....。
不过,这种话,不受人待见。
在mailing list中有人用论坛来提供python学习的场所,我说了以下的话。
在blog当道的今天,论坛的局限性越来越明显。理由很明显:
从长远来看:谁都不会无原则地贡献自己所写的内容。
 
不过,只要肯坚持下去,未尝不是一个学习python的去处的选择
可能是我有所期待,所以才会如此。或是做梦是最容易的一件事,我不费力气就说了上面的话。
好了,不说了。
 
2006年04月02日

 在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 ,这一句话,与我的思路不一致,暂且存疑)


可以看出,动态的名字空间查找过程。名字是在名字空间中,名字空间有名字。在某种程度上就是一个东西。


 

2006年04月01日

以前的管理员都是静态的,需要被任命。这对于严肃的组织
很必要。但这也很死板。而且很受制于某个超级管理员,深深地打下其烙印。典型的现在的论坛就是这样。大多数总是问一些翻来覆去的问题。因为发问的过程没有任何的代价,也没有任何的益处。


 


如果管理是自组织的。首先按提交被通过的次数自动升级为具有一定的权力。随后再次提升。通过提交而来可以获得另处的收益。谁都会注重提交的质量。没有谁会一如既往无收益坚持提交。只有提交的行为本身就是一种益处。大家就可以注重这种行为。一个人的行为得以检点,对整个社区来讲,所有人的行为都可能提高。社区就激发了所有人的力量。这才是社区的真正意义。

2006年03月28日

我觉得肯定会,不过是以python自己的方式。向别的语言学习是python的特色,例如从ABC、modula-3等语言中。它现在从ruby学习也是一种很正常的事,而且也很必要。肯定会向ruby借鉴某些东西的,ruby不也有python的东西吗。引入ruby的block等不是难事。


python如果不创新,而ruby在继续发展的话,就太被动。


相对于ruby,python应该学习其长处。创不创新,有多大的创新,有比较,才能知道得更清楚。


当对于ruby on rails,发出这样的感叹时:python  也能作这样的东西啊!就知道ruby已经有了自己的


步伐了。ruby是python之外的另一种选择。


 


 



 

2006年03月22日

python是有弱点的,任何语言都有弱点。这里我想谈其中的一个方面。我说过python和ruby没有什么不同。我更多的是认为ruby是作为python的竟争者出现的。两个语言有太多的相似点,而与perl有较大的区别。如果在面向对象的脚本语言世界中,ruby三分天下有其一,那么可以说就是python给的。python在他年幼的时候,创新的步伐太慢,以至于ruby的开发者认为,应该有比python更好的东西,结果ruby就出现了。作为语言的学习者,学习两个太相似的东西,徒然浪费精力。


         可是现实世界的法则,不管是白猫还是黑猫,能抓到老鼠的就是好猫。实用主义至上吧。


可以这么说,ruby能走多远,就是python的语言的弱点有多弱。当年多少人认为python是明日的新星


,结果至今未入主流。为什么它入不了主流,因为有ruby存在。同理,那些期盼ruby入主流的,


要想一想与你太相似的对手,现在走了多远。


 


 

2006年03月21日


“我一直在忍耐,那种一看上去让人脑袋嗡的一声的界面,真是复杂。”

“神啊,Pythonic不应该是这样的吧,笨人在Python里面就没有办法立足吗?”

我以前说过,它的界面相当ugly。看到这个问题,勾起以前的想法了。


倒不是说MoinMoin的不好,原先www.python.org的页面,就是MoinMoin的,后来才知道

MoinMoin也可以弄得不错的。

 

很多东西是有比较才有差别,外面流行的页面与其一比较,立马受刺激。

 

作为技术性的社区,最重要的就是参与及认同。关于维护,首先要认同,

连认同都没有,能谈其它的吗?

 

本来作为技术性社区,最不缺的就是维护。最容易聚集的就是这种力量。

但是现在……。不说了。

 

ruby和python没有什么在本质上不同,更多的是冲着python的某些弱点去的。

有竟争者才好,要不就很容易自大。

 

也希望出现另一个强有力的python社区。聚集了人气就是硬道理。

不过从一个侧面说明,python在中国不流行。在一些python爱好者里面,

它的中文社区也不过如此。在其它人眼里,可见一斑。