看jam.zhang的信有感而发。

Python虽然很棒，但也不是包打天下的。现在Python 3000的PEP已经出来了，我们是不是可以讨论一下，Python
3.0应该有哪些特性，怎样使他变得更强大，更方便。不过大家在发帖子之前先去看看
http://www.python.org/peps/pep-3000.html，重复的就别提了。

这里我先讲讲我的意见，算是抛砖引玉吧。

1. interface   
zope和twisted都不约而同地实现了自己的interface，说明这确实是一个很重要的feature。Python 3应该把它补上。

2. __range__
for i in range(3)，不能说这种写法不好，但是Perl和Ruby的1..3 不是更方便吗？建议能让同志们重载 .. (两个点) 运算符

3. private，public，friend
用类似@property, @classmethod的手段提供private,
public和friend的访问控制。这个feature和interface的实现紧密相关。

shhgs wrote:

>看jam.zhang的信有感而发。
>
>Python虽然很棒，但也不是包打天下的。现在Python 3000的PEP已经出来了，我们是不是可以讨论一下，Python
>3.0应该有哪些特性，怎样使他变得更强大，更方便。不过大家在发帖子之前先去看看
>http://www.python.org/peps/pep-3000.html，重复的就别提了。
>
>这里我先讲讲我的意见，算是抛砖引玉吧。
>
>1. interface   
>zope和twisted都不约而同地实现了自己的interface，说明这确实是一个很重要的feature。Python 3应该把它补上。
>  
>
这个很重要吗？动态语言里，interface只是象征意义。
如果实现了interface，那么对于一个未实现的方法methodA，它的调用应该会有什 
么结果？我想应该是抛出 NotImplementedError吧，如果只是这么简单，那么自己 
就可以实现了。

>2. __range__
>for i in range(3)，不能说这种写法不好，但是Perl和Ruby的1..3 不是更方便吗？建议能让同志们重载 .. (两个点) 运算符
>  
>
如果加上这个，调用习惯可能要改为：
class A:
    def __range__ (self, start, end):
        。。。

for i in A():
    ...

如果仅仅这样，那么__iter__比这个更通用(迭代器模式)，而且实现也要简单，如 
果增加一种语法不能带来显著的编程效率的提升，那其实就是不必要的，反而让语 
法更复杂，而且python也没有必要兼容其它语言的语法。

>3. private，public，friend
>用类似@property, @classmethod的手段提供private,
>public和friend的访问控制。这个feature和interface的实现紧密相关。
>  
>
>  
>
python的访问控制是基于命名约定的，这是它的特色。

property已经从python2.2开始提供：

class C(object):
    def getx(self):
        print 'getter'
        return self.__x
    def setx(self, value):
        print 'setter'
        self.__x = value
    def delx(self):
        del self.__x
    x = property(getx, setx, delx, "I'm the 'x' property.")

 >>> c = C()
 >>> c.x = 'a'
setter
 >>> print c.x
getter
a
 >>>

classmethod是什么？如果是普通的成员方法，则默认就是；如果是static 
method，则有@staticmethod(python2.4)。

>------------------------------------------------------------------------
>
>_______________________________________________
>python-chinese list
>python-chinese at lists.python.cn
>http://python.cn/mailman/listinfo/python-chinese
>  
>

赞！！！
Python 有自个儿的个性，不能因为不了解，或是羡慕流行的东西就不使用已有的优美……

2005/6/29, cpunion <cpunion at 263.net>:
> 
> 
> shhgs wrote:
> 
> >看jam.zhang的信有感而发。
> >
> >Python虽然很棒，但也不是包打天下的。现在Python 3000的PEP已经出来了，我们是不是可以讨论一下，Python
> >3.0应该有哪些特性，怎样使他变得更强大，更方便。不过大家在发帖子之前先去看看
> >http://www.python.org/peps/pep-3000.html，重复的就别提了。
> >
> >这里我先讲讲我的意见，算是抛砖引玉吧。
> >
> >1. interface
> >zope和twisted都不约而同地实现了自己的interface，说明这确实是一个很重要的feature。Python 3应该把它补上。
> >
> >
> 这个很重要吗？动态语言里，interface只是象征意义。
> 如果实现了interface，那么对于一个未实现的方法methodA，它的调用应该会有什
> 么结果？我想应该是抛出 NotImplementedError吧，如果只是这么简单，那么自己
> 就可以实现了。
> 
> >2. __range__
> >for i in range(3)，不能说这种写法不好，但是Perl和Ruby的1..3 不是更方便吗？建议能让同志们重载 .. (两个点) 运算符
> >
> >
> 如果加上这个，调用习惯可能要改为：
> class A:
>     def __range__ (self, start, end):
>         。。。
> 
> for i in A():
>     ...
> 
> 如果仅仅这样，那么__iter__比这个更通用(迭代器模式)，而且实现也要简单，如
> 果增加一种语法不能带来显著的编程效率的提升，那其实就是不必要的，反而让语
> 法更复杂，而且python也没有必要兼容其它语言的语法。
> 
> >3. private，public，friend
> >用类似@property, @classmethod的手段提供private,
> >public和friend的访问控制。这个feature和interface的实现紧密相关。
> >
> >
> >
> >
> python的访问控制是基于命名约定的，这是它的特色。
> 
> property已经从python2.2开始提供：
> 
> class C(object):
>     def getx(self):
>         print 'getter'
>         return self.__x
>     def setx(self, value):
>         print 'setter'
>         self.__x = value
>     def delx(self):
>         del self.__x
>     x = property(getx, setx, delx, "I'm the 'x' property.")
> 
>  >>> c = C()
>  >>> c.x = 'a'
> setter
>  >>> print c.x
> getter
> a
>  >>>
> 
> classmethod是什么？如果是普通的成员方法，则默认就是；如果是static
> method，则有@staticmethod(python2.4)。
> 
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >python-chinese list
> >python-chinese at lists.python.cn
> >http://python.cn/mailman/listinfo/python-chinese
> >
> >
> _______________________________________________
> python-chinese list
> python-chinese at lists.python.cn
> http://python.cn/mailman/listinfo/python-chinese
> 


-- 
[Time is unimportant, only life important!]

很遗憾，一个知音都没找到，不过我还是坚持我的看法。

1。Interface很重要，它是解决Python多重继承和MRO问题的最佳途径。如果真的向你们说的那样无聊，Zope和Twisted就不用费劲巴力地去搞一个了。

2。自从用了Python，我就再也没有留恋过Perl。不过有一个小小的例外，就是在写range(10) 的时候。我时常情不自禁地写for i
in [1..3]。此外Python没有提供enumeration，__range__也可以借此补上这个空白。

3。private，public，和friend。并不是他们不重要，而是Python的实现比较困难。Python可以在对象的实例化之后再绑定方法，所以实现private有一定的难度。如果你把一个方法定义为private的，过一会用户再绑定了一个同名的方法，请问这个方法到底算不算，怎么算。但是有难度不是说没必要。否则Guido根本没必要去搞什么__XXX的方法名混淆。

在 05-6-29，shhgs<shhgs.efhilt at gmail.com> 写道：
> 很遗憾，一个知音都没找到，不过我还是坚持我的看法。
> 
> 1。Interface很重要，它是解决Python多重继承和MRO问题的最佳途径。如果真的向你们说的那样无聊，Zope和Twisted就不用费劲巴力地去搞一个了。
> 
> 2。自从用了Python，我就再也没有留恋过Perl。不过有一个小小的例外，就是在写range(10) 的时候。我时常情不自禁地写for i
> in [1..3]。此外Python没有提供enumeration，__range__也可以借此补上这个空白。

因为我没有用过1..3因此也从来没有留恋过。
> 
> 3。private，public，和friend。并不是他们不重要，而是Python的实现比较困难。Python可以在对象的实例化之后再绑定方法，所以实现private有一定的难度。如果你把一个方法定义为private的，过一会用户再绑定了一个同名的方法，请问这个方法到底算不算，怎么算。但是有难度不是说没必要。否则Guido根本没必要去搞什么__XXX的方法名混淆。
> 
对于我个人来说，我更习惯于约定，因为程序都是自已的。这些东西对于象Java的东西非常
有用，尤其人多人开发时。Python下也许有用。我也说不清。如果作为可选特性也无所谓，想用就用，不想用就不用。
> _______________________________________________
> python-chinese list
> python-chinese at lists.python.cn
> http://python.cn/mailman/listinfo/python-chinese
> 
> 
> 


-- 
I like python! 
My Donews Blog: http://www.donews.net/limodou
New Google Maillist: http://groups-beta.google.com/group/python-cn

Interface还是很有用的
在面向对象的时候通过接口可以隐藏对象内部的实现细节
对象的接口和对象的功能应该完全分开
尽量避免其它人访问内部变量和函数对对象造成破坏
虽然现在可以模拟接口，但是作为一个面向对象的语言应该加入interface

在05-6-29，shhgs <shhgs.efhilt at gmail.com> 写道：
> 
> 很遗憾，一个知音都没找到，不过我还是坚持我的看法。
> 
> 
> 1。Interface很重要，它是解决Python多重继承和MRO问题的最佳途径。如果真的向你们说的那样无聊，Zope和Twisted就不用费劲巴力地去搞一个了。
> 
> 2。自从用了Python，我就再也没有留恋过Perl。不过有一个小小的例外，就是在写range(10) 的时候。我时常情不自禁地写for i
> in [1..3]。此外Python没有提供enumeration，__range__也可以借此补上这个空白。
> 
> 
> 3。private，public，和friend。并不是他们不重要，而是Python的实现比较困难。Python可以在对象的实例化之后再绑定方法，所以实现private有一定的难度。如果你把一个方法定义为private的，过一会用户再绑定了一个同名的方法，请问这个方法到底算不算，怎么算。但是有难度不是说没必要。否则Guido根本没必要去搞什么__XXX的方法名混淆。
> 
> _______________________________________________
> python-chinese list
> python-chinese at lists.python.cn
> http://python.cn/mailman/listinfo/python-chinese
> 
> 
> 


-- 
I'm the one, powered by nEO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20050629/aa6a5240/attachment.html

在下没有用到这样的高级功能过，所以没有发言权，

兄台们，可以介绍一下子 Interface 的实际应用情况？

在 05-6-29，nEO<gentoo.cn at gmail.com> 写道：
> Interface还是很有用的
>  在面向对象的时候通过接口可以隐藏对象内部的实现细节
>  对象的接口和对象的功能应该完全分开
>  尽量避免其它人访问内部变量和函数对对象造成破坏
>  虽然现在可以模拟接口，但是作为一个面向对象的语言应该加入interface
> 
> 在05-6-29，shhgs <shhgs.efhilt at gmail.com> 写道：
> > 
> > 很遗憾，一个知音都没找到，不过我还是坚持我的看法。
> > 
> >
> 1。Interface很重要，它是解决Python多重继承和MRO问题的最佳途径。如果真的向你们说的那样无聊，Zope和Twisted就不用费劲巴力地去搞一个了。
> > 
> > 2。自从用了Python，我就再也没有留恋过Perl。不过有一个小小的例外，就是在写range(10)
> 的时候。我时常情不自禁地写for i
> > in [1..3]。此外Python没有提供enumeration，__range__也可以借此补上这个空白。 
> > 
> >
> 3。private，public，和friend。并不是他们不重要，而是Python的实现比较困难。Python可以在对象的实例化之后再绑定方法，所以实现private有一定的难度。如果你把一个方法定义为private的，过一会用户再绑定了一个同名的方法，请问这个方法到底算不算，怎么算。但是有难度不是说没必要。否则Guido根本没必要去搞什么__XXX的方法名混淆。
> > 
> > _______________________________________________ 
> > python-chinese list
> > python-chinese at lists.python.cn
> > http://python.cn/mailman/listinfo/python-chinese 
> > 
> > 
> > 
> 
> 
> 
> -- 
> I'm the one, powered by nEO 
> _______________________________________________
> python-chinese list
> python-chinese at lists.python.cn
> http://python.cn/mailman/listinfo/python-chinese
> 
> 
> 


-- 
[Time is unimportant, only life important!]

这个其实是习惯的问题，C++没出来以前，大家用C是怎么做的？

C++（或其类似的语言）形成习惯以后，很多东西就是觉得必然像C++才好，比如
JAVA就是这样。

JAVA在WEB上的应用形成习惯以后，大家也就觉得一定要写成某种形式的
interfaces，才能扩展，这个也是习惯。

静态语言中interface是必须的，因为变量必须声明一个类型，而这个类型又要能
表现出所操作对象的基本方法集合，于是就形成interface语法。

但动态语言中，这个不是必须的，如果认为这个是必须的，那就是从JAVA中带来的
习惯，可以简单问一下：为何只有PYTHON应用到WEB领域后，才有人想起来需要
interface?

再来解释一下，为何java中一定要interface，因为java只支持“面向对象”这一种
编程范式，interface是在面向对象范式中用到的，所以是必须。而C++支持4种以
上，python呢？比C++更多。

interface只在继承体系中才有意义，如果我们不使用继承，那么interface就毫无
意义了，其它的选择真的很多，我昨天在啄木鸟上发的一个委托功能的python实
现，其实也算一种解决方案（我只是简单模仿C#委托）。

一个系统可以全部采用委托来设计，可以把完全避免继承。采用委托来设计，可以
拿电路板作比较：电路板上只有一些基本元素（电容、电阻、电感、二极管、三极
管等等），可曾看到大规模的继承体系？各个元件的每个输入极就是一个调用接
口，每个输出极就是一个委托，一个子模块可由多个元件之间的委托和调用接口藕
合而成，整个系统可由多个子模块藕合而成。各个元件（应该说各类，因为只要类
是好的，那么可认为各个元件也是好的）可单独测试，可以很方便的配置测试环
境，各个模块也可以这样测试，整个系统各模块之间只是简单遵守接口协议，并没
有真正的形成一个接口。

只是有一点很遗憾，由于JAVA本身的成功，编程被引导到继承体系中了，可能是因
为这个是最容易实现的吧，但并不是说它是最合理的体系，对python这样的动态语
言来说，使用继承我认为仅仅是长久形成的编程习惯，而不是最理想的。

最后举个简单例子，解释继承和委托之间的区别：

继承：
class 人：
def on肚子痛(self):
pass

class 穷人(人)：
def on肚子痛(self):
self.用手揉()

class 富人（人）：
def on肚子痛(self):
self.找医生()

委托（使用我写的那个delegate类）：
class 人：
def __init__(self):
self.on肚子痛 = deletate (proto='on肚子痛()')

def 找医生（）：
pass

def 用手揉（）：
pass

穷人 ＝ 人（）
富人 ＝ 人（）
穷人.on肚子痛 += 用手揉
副人.on肚子痛 += 找医生

从这里看，比继承好的一点是：穷人富人都是人，他们别的方面可能都一样，可以
细微调整某个不同的地方。

注：上面用的+=符号是迫不得已，因为不能直接用=。（如果用：穷人.on肚子痛 =
delegate(用手揉)也是可以的)

shhgs 写道:

>很遗憾，一个知音都没找到，不过我还是坚持我的看法。
>
>1。Interface很重要，它是解决Python多重继承和MRO问题的最佳途径。如果真的向你们说的那样无聊，Zope和Twisted就不用费劲巴力地去搞一个了。
>
>2。自从用了Python，我就再也没有留恋过Perl。不过有一个小小的例外，就是在写range(10) 的时候。我时常情不自禁地写for i
>in [1..3]。此外Python没有提供enumeration，__range__也可以借此补上这个空白。
>
>3。private，public，和friend。并不是他们不重要，而是Python的实现比较困难。Python可以在对象的实例化之后再绑定方法，所以实现private有一定的难度。如果你把一个方法定义为private的，过一会用户再绑定了一个同名的方法，请问这个方法到底算不算，怎么算。但是有难度不是说没必要。否则Guido根本没必要去搞什么__XXX的方法名混淆。
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>python-chinese list
>python-chinese at lists.python.cn
>http://python.cn/mailman/listinfo/python-chinese
>  
>

很有意思。但是你写这个delegate不正说明interface的重要性吗？如果有了interface你还要去写这个delegate吗？直接implement岂不是更方便？

其实某种功能，任何一种语言都能实现。C也可以OOP，但是有为什么它不能算是OOP的语言呢？Python是用来帮助我们提高开发效率的，所以不是说这个东西Python能实现，我们就不用加了。2.4加的那个Set就是例子。2.3之前我曾经自己写过Set，但现在用标准类库的，不但性能高，用着也放心。

On 6/29/05, cpunion <cpunion at 263.net> wrote:
> 这个其实是习惯的问题，C++没出来以前，大家用C是怎么做的？
> 
> C++（或其类似的语言）形成习惯以后，很多东西就是觉得必然像C++才好，比如
> JAVA就是这样。
> 
> JAVA在WEB上的应用形成习惯以后，大家也就觉得一定要写成某种形式的
> interfaces，才能扩展，这个也是习惯。
> 
> 静态语言中interface是必须的，因为变量必须声明一个类型，而这个类型又要能
> 表现出所操作对象的基本方法集合，于是就形成interface语法。
> 
> 但动态语言中，这个不是必须的，如果认为这个是必须的，那就是从JAVA中带来的
> 习惯，可以简单问一下：为何只有PYTHON应用到WEB领域后，才有人想起来需要
> interface?
> 
> 再来解释一下，为何java中一定要interface，因为java只支持"面向对象"这一种
> 编程范式，interface是在面向对象范式中用到的，所以是必须。而C++支持4种以
> 上，python呢？比C++更多。
> 
> interface只在继承体系中才有意义，如果我们不使用继承，那么interface就毫无
> 意义了，其它的选择真的很多，我昨天在啄木鸟上发的一个委托功能的python实
> 现，其实也算一种解决方案（我只是简单模仿C#委托）。
> 
> 一个系统可以全部采用委托来设计，可以把完全避免继承。采用委托来设计，可以
> 拿电路板作比较：电路板上只有一些基本元素（电容、电阻、电感、二极管、三极
> 管等等），可曾看到大规模的继承体系？各个元件的每个输入极就是一个调用接
> 口，每个输出极就是一个委托，一个子模块可由多个元件之间的委托和调用接口藕
> 合而成，整个系统可由多个子模块藕合而成。各个元件（应该说各类，因为只要类
> 是好的，那么可认为各个元件也是好的）可单独测试，可以很方便的配置测试环
> 境，各个模块也可以这样测试，整个系统各模块之间只是简单遵守接口协议，并没
> 有真正的形成一个接口。
> 
> 只是有一点很遗憾，由于JAVA本身的成功，编程被引导到继承体系中了，可能是因
> 为这个是最容易实现的吧，但并不是说它是最合理的体系，对python这样的动态语
> 言来说，使用继承我认为仅仅是长久形成的编程习惯，而不是最理想的。
> 
> 最后举个简单例子，解释继承和委托之间的区别：
> 
> 继承：
> class 人：
> def on肚子痛(self):
> pass
> 
> class 穷人(人)：
> def on肚子痛(self):
> self.用手揉()
> 
> class 富人（人）：
> def on肚子痛(self):
> self.找医生()
> 
> 委托（使用我写的那个delegate类）：
> class 人：
> def __init__(self):
> self.on肚子痛 = deletate (proto='on肚子痛()')
> 
> def 找医生（）：
> pass
> 
> def 用手揉（）：
> pass
> 
> 穷人 ＝ 人（）
> 富人 ＝ 人（）
> 穷人.on肚子痛 += 用手揉
> 副人.on肚子痛 += 找医生
> 
> 从这里看，比继承好的一点是：穷人富人都是人，他们别的方面可能都一样，可以
> 细微调整某个不同的地方。
> 
> 注：上面用的+=符号是迫不得已，因为不能直接用=。（如果用：穷人.on肚子痛 =
> delegate(用手揉)也是可以的)
> 
> shhgs 写道:
> 
> >很遗憾，一个知音都没找到，不过我还是坚持我的看法。
> >
> >1。Interface很重要，它是解决Python多重继承和MRO问题的最佳途径。如果真的向你们说的那样无聊，Zope和Twisted就不用费劲巴力地去搞一个了。
> >
> >2。自从用了Python，我就再也没有留恋过Perl。不过有一个小小的例外，就是在写range(10) 的时候。我时常情不自禁地写for i
> >in [1..3]。此外Python没有提供enumeration，__range__也可以借此补上这个空白。
> >
> >3。private，public，和friend。并不是他们不重要，而是Python的实现比较困难。Python可以在对象的实例化之后再绑定方法，所以实现private有一定的难度。如果你把一个方法定义为private的，过一会用户再绑定了一个同名的方法，请问这个方法到底算不算，怎么算。但是有难度不是说没必要。否则Guido根本没必要去搞什么__XXX的方法名混淆。
> >
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >python-chinese list
> >python-chinese at lists.python.cn
> >http://python.cn/mailman/listinfo/python-chinese
> >
> >
> _______________________________________________
> python-chinese list
> python-chinese at lists.python.cn
> http://python.cn/mailman/listinfo/python-chinese
>

我想Python以后想深入到企业级应用的开发，必然需要象Java一样严格，这主要是要减少错误的发生。如果是个人开发，写一些小程序，这些问题的确不用考虑。但在一个大型开发过程中，靠文档，靠约定其实还是不够的。最后能变成靠ＩＤＥ可能就差不多了。但不知道这些东西对Python的影响有多大。

在 05-6-30，shhgs<shhgs.efhilt at gmail.com> 写道：
> 很有意思。但是你写这个delegate不正说明interface的重要性吗？如果有了interface你还要去写这个delegate吗？直接implement岂不是更方便？
> 
> 其实某种功能，任何一种语言都能实现。C也可以OOP，但是有为什么它不能算是OOP的语言呢？Python是用来帮助我们提高开发效率的，所以不是说这个东西Python能实现，我们就不用加了。2.4加的那个Set就是例子。2.3之前我曾经自己写过Set，但现在用标准类库的，不但性能高，用着也放心。
> 
> On 6/29/05, cpunion <cpunion at 263.net> wrote:
> > 这个其实是习惯的问题，C++没出来以前，大家用C是怎么做的？
> >
> > C++（或其类似的语言）形成习惯以后，很多东西就是觉得必然像C++才好，比如
> > JAVA就是这样。
> >
> > JAVA在WEB上的应用形成习惯以后，大家也就觉得一定要写成某种形式的
> > interfaces，才能扩展，这个也是习惯。
> >
> > 静态语言中interface是必须的，因为变量必须声明一个类型，而这个类型又要能
> > 表现出所操作对象的基本方法集合，于是就形成interface语法。
> >
> > 但动态语言中，这个不是必须的，如果认为这个是必须的，那就是从JAVA中带来的
> > 习惯，可以简单问一下：为何只有PYTHON应用到WEB领域后，才有人想起来需要
> > interface?
> >
> > 再来解释一下，为何java中一定要interface，因为java只支持"面向对象"这一种
> > 编程范式，interface是在面向对象范式中用到的，所以是必须。而C++支持4种以
> > 上，python呢？比C++更多。
> >
> > interface只在继承体系中才有意义，如果我们不使用继承，那么interface就毫无
> > 意义了，其它的选择真的很多，我昨天在啄木鸟上发的一个委托功能的python实
> > 现，其实也算一种解决方案（我只是简单模仿C#委托）。
> >
> > 一个系统可以全部采用委托来设计，可以把完全避免继承。采用委托来设计，可以
> > 拿电路板作比较：电路板上只有一些基本元素（电容、电阻、电感、二极管、三极
> > 管等等），可曾看到大规模的继承体系？各个元件的每个输入极就是一个调用接
> > 口，每个输出极就是一个委托，一个子模块可由多个元件之间的委托和调用接口藕
> > 合而成，整个系统可由多个子模块藕合而成。各个元件（应该说各类，因为只要类
> > 是好的，那么可认为各个元件也是好的）可单独测试，可以很方便的配置测试环
> > 境，各个模块也可以这样测试，整个系统各模块之间只是简单遵守接口协议，并没
> > 有真正的形成一个接口。
> >
> > 只是有一点很遗憾，由于JAVA本身的成功，编程被引导到继承体系中了，可能是因
> > 为这个是最容易实现的吧，但并不是说它是最合理的体系，对python这样的动态语
> > 言来说，使用继承我认为仅仅是长久形成的编程习惯，而不是最理想的。
> >
> > 最后举个简单例子，解释继承和委托之间的区别：
> >
> > 继承：
> > class 人：
> > def on肚子痛(self):
> > pass
> >
> > class 穷人(人)：
> > def on肚子痛(self):
> > self.用手揉()
> >
> > class 富人（人）：
> > def on肚子痛(self):
> > self.找医生()
> >
> > 委托（使用我写的那个delegate类）：
> > class 人：
> > def __init__(self):
> > self.on肚子痛 = deletate (proto='on肚子痛()')
> >
> > def 找医生（）：
> > pass
> >
> > def 用手揉（）：
> > pass
> >
> > 穷人 ＝ 人（）
> > 富人 ＝ 人（）
> > 穷人.on肚子痛 += 用手揉
> > 副人.on肚子痛 += 找医生
> >
> > 从这里看，比继承好的一点是：穷人富人都是人，他们别的方面可能都一样，可以
> > 细微调整某个不同的地方。
> >
> > 注：上面用的+=符号是迫不得已，因为不能直接用=。（如果用：穷人.on肚子痛 =
> > delegate(用手揉)也是可以的)
> >
> > shhgs 写道:
> >
> > >很遗憾，一个知音都没找到，不过我还是坚持我的看法。
> > >
> > >1。Interface很重要，它是解决Python多重继承和MRO问题的最佳途径。如果真的向你们说的那样无聊，Zope和Twisted就不用费劲巴力地去搞一个了。
> > >
> > >2。自从用了Python，我就再也没有留恋过Perl。不过有一个小小的例外，就是在写range(10) 的时候。我时常情不自禁地写for i
> > >in [1..3]。此外Python没有提供enumeration，__range__也可以借此补上这个空白。
> > >
> > >3。private，public，和friend。并不是他们不重要，而是Python的实现比较困难。Python可以在对象的实例化之后再绑定方法，所以实现private有一定的难度。如果你把一个方法定义为private的，过一会用户再绑定了一个同名的方法，请问这个方法到底算不算，怎么算。但是有难度不是说没必要。否则Guido根本没必要去搞什么__XXX的方法名混淆。
> > >
> > >
> > >------------------------------------------------------------------------
> > >
> > >_______________________________________________
> > >python-chinese list
> > >python-chinese at lists.python.cn
> > >http://python.cn/mailman/listinfo/python-chinese
> > >
> > >
> > _______________________________________________
> > python-chinese list
> > python-chinese at lists.python.cn
> > http://python.cn/mailman/listinfo/python-chinese
> >
> 
> _______________________________________________
> python-chinese list
> python-chinese at lists.python.cn
> http://python.cn/mailman/listinfo/python-chinese
> 
> 
> 


-- 
I like python! 
My Donews Blog: http://www.donews.net/limodou
New Google Maillist: http://groups-beta.google.com/group/python-cn

在05-6-30，shhgs <shhgs.efhilt at gmail.com> 写道：
为什么有Interface的情况下我就不用写委托？就算在C#下，我也经常用委托而不是继承，过多使用继承会导致结构复杂笨重。有了车还要有船吗？要， 
因为它们的用途不同。在Java中也许继承更方便，但在Python中就未必了。何必要把Java中那一套搬过来呢？每一种语言都有它的特色，应该正视。 
Interface在我看来意义无非是在CLI/Java这样的虚拟机环境下，和其它语言提供兼容。如果不在乎这种兼容，没有它也没什么不可以。

> 
> 很有意思。但是你写这个delegate不正说明interface的重要性吗？如果有了interface你还要去写这个delegate吗？直接implement岂不是更方便？
> 
> 
> 其实某种功能，任何一种语言都能实现。C也可以OOP，但是有为什么它不能算是OOP的语言呢？Python是用来帮助我们提高开发效率的，所以不是说这个东西Python能实现，我们就不用加了。2.4加的那个Set就是例子。2.3之前我曾经自己写过Set，但现在用标准类库的，不但性能高，用着也放心。
> 
> On 6/29/05, cpunion <cpunion at 263.net> wrote:
> > 这个其实是习惯的问题，C++没出来以前，大家用C是怎么做的？
> >
> > C++（或其类似的语言）形成习惯以后，很多东西就是觉得必然像C++才好，比如
> > JAVA就是这样。
> >
> > JAVA在WEB上的应用形成习惯以后，大家也就觉得一定要写成某种形式的
> > interfaces，才能扩展，这个也是习惯。
> >
> > 静态语言中interface是必须的，因为变量必须声明一个类型，而这个类型又要能
> > 表现出所操作对象的基本方法集合，于是就形成interface语法。
> >
> > 但动态语言中，这个不是必须的，如果认为这个是必须的，那就是从JAVA中带来的
> > 习惯，可以简单问一下：为何只有PYTHON应用到WEB领域后，才有人想起来需要
> > interface?
> >
> > 再来解释一下，为何java中一定要interface，因为java只支持"面向对象"这一种
> > 编程范式，interface是在面向对象范式中用到的，所以是必须。而C++支持4种以
> > 上，python呢？比C++更多。
> >
> > interface只在继承体系中才有意义，如果我们不使用继承，那么interface就毫无
> > 意义了，其它的选择真的很多，我昨天在啄木鸟上发的一个委托功能的python实
> > 现，其实也算一种解决方案（我只是简单模仿C#委托）。
> >
> > 一个系统可以全部采用委托来设计，可以把完全避免继承。采用委托来设计，可以
> > 拿电路板作比较：电路板上只有一些基本元素（电容、电阻、电感、二极管、三极
> > 管等等），可曾看到大规模的继承体系？各个元件的每个输入极就是一个调用接
> > 口，每个输出极就是一个委托，一个子模块可由多个元件之间的委托和调用接口藕
> > 合而成，整个系统可由多个子模块藕合而成。各个元件（应该说各类，因为只要类
> > 是好的，那么可认为各个元件也是好的）可单独测试，可以很方便的配置测试环
> > 境，各个模块也可以这样测试，整个系统各模块之间只是简单遵守接口协议，并没
> > 有真正的形成一个接口。
> >
> > 只是有一点很遗憾，由于JAVA本身的成功，编程被引导到继承体系中了，可能是因
> > 为这个是最容易实现的吧，但并不是说它是最合理的体系，对python这样的动态语
> > 言来说，使用继承我认为仅仅是长久形成的编程习惯，而不是最理想的。
> >
> > 最后举个简单例子，解释继承和委托之间的区别：
> >
> > 继承：
> > class 人：
> > def on肚子痛(self):
> > pass
> >
> > class 穷人(人)：
> > def on肚子痛(self):
> > self.用手揉()
> >
> > class 富人（人）：
> > def on肚子痛(self):
> > self.找医生()
> >
> > 委托（使用我写的那个delegate类）：
> > class 人：
> > def __init__(self):
> > self.on肚子痛 = deletate (proto='on肚子痛()')
> >
> > def 找医生（）：
> > pass
> >
> > def 用手揉（）：
> > pass
> >
> > 穷人 ＝ 人（）
> > 富人 ＝ 人（）
> > 穷人.on肚子痛 += 用手揉
> > 副人.on肚子痛 += 找医生
> >
> > 从这里看，比继承好的一点是：穷人富人都是人，他们别的方面可能都一样，可以
> > 细微调整某个不同的地方。
> >
> > 注：上面用的+=符号是迫不得已，因为不能直接用=。（如果用：穷人.on肚子痛 =
> > delegate(用手揉)也是可以的)
> >
> > shhgs 写道:
> >
> > >很遗憾，一个知音都没找到，不过我还是坚持我的看法。
> > >
> > 
> >1。Interface很重要，它是解决Python多重继承和MRO问题的最佳途径。如果真的向你们说的那样无聊，Zope和Twisted就不用费劲巴力地去搞一个了。
> > >
> > >2。自从用了Python，我就再也没有留恋过Perl。不过有一个小小的例外，就是在写range(10) 的时候。我时常情不自禁地写for i
> > >in [1..3]。此外Python没有提供enumeration，__range__也可以借此补上这个空白。
> > >
> > 
> >3。private，public，和friend。并不是他们不重要，而是Python的实现比较困难。Python可以在对象的实例化之后再绑定方法，所以实现private有一定的难度。如果你把一个方法定义为private的，过一会用户再绑定了一个同名的方法，请问这个方法到底算不算，怎么算。但是有难度不是说没必要。否则Guido根本没必要去搞什么__XXX的方法名混淆。
> > >
> > >
> > 
> >------------------------------------------------------------------------
> > >
> > >_______________________________________________
> > >python-chinese list
> > >python-chinese at lists.python.cn
> > >http://python.cn/mailman/listinfo/python-chinese
> > >
> > >
> > _______________________________________________
> > python-chinese list
> > python-chinese at lists.python.cn
> > http://python.cn/mailman/listinfo/python-chinese
> >
> 
> _______________________________________________
> python-chinese list
> python-chinese at lists.python.cn
> http://python.cn/mailman/listinfo/python-chinese
> 
> 
> 


-- 
欢迎访问：
http://blog.csdn.net/ccat

刘鑫
March.Liu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20050630/066f33be/attachment.html

我认为有没有interface不是一个习惯问题，而是在面向方法分析/设计中有它真正
的位置。
至于为什么，我建议可以看看“设计模式”里面的论述，里面说道了为什么要面向
接口编程。
更理论的东西我也没有看过。。。：）

》》》可以简单问一下：为何只有PYTHON应用到WEB领域后，才有人想起来需要
interface?
是的，做一些日常管理，文本分析之类的程序没人会抱怨python没有提供
interface，
但在web领域，提出了interface的要求，why？
我认为更多的不是java遗留的习惯，而是领域本身对面向对象语言的自然要求。

我是java过来的，我个人感觉对于多层的程序，自然会对interface提出要求。
所以，我觉得interface，访问控制是应该加入python的。



-----Original Message-----
From: python-chinese-bounces at lists.python.cn
[mailto:python-chinese-bounces at lists.python.cn] On Behalf Of cpunion
Sent: Wednesday, June 29, 2005 11:19 PM
To: python-chinese at lists.python.cn
Subject: Re: [python-chinese] 大家对PEP 3000有什么看法？


这个其实是习惯的问题，C++没出来以前，大家用C是怎么做的？

C++（或其类似的语言）形成习惯以后，很多东西就是觉得必然像C++才好，比如
JAVA就是这样。

JAVA在WEB上的应用形成习惯以后，大家也就觉得一定要写成某种形式的
interfaces，才能扩展，这个也是习惯。

静态语言中interface是必须的，因为变量必须声明一个类型，而这个类型又要能
表现出所操作对象的基本方法集合，于是就形成interface语法。

但动态语言中，这个不是必须的，如果认为这个是必须的，那就是从JAVA中带来的
习惯，可以简单问一下：为何只有PYTHON应用到WEB领域后，才有人想起来需要
interface?

再来解释一下，为何java中一定要interface，因为java只支持“面向对象”这一
种
编程范式，interface是在面向对象范式中用到的，所以是必须。而C++支持4种以
上，python呢？比C++更多。

interface只在继承体系中才有意义，如果我们不使用继承，那么interface就毫无
意义了，其它的选择真的很多，我昨天在啄木鸟上发的一个委托功能的python实
现，其实也算一种解决方案（我只是简单模仿C#委托）。

一个系统可以全部采用委托来设计，可以把完全避免继承。采用委托来设计，可以
拿电路板作比较：电路板上只有一些基本元素（电容、电阻、电感、二极管、三极
管等等），可曾看到大规模的继承体系？各个元件的每个输入极就是一个调用接
口，每个输出极就是一个委托，一个子模块可由多个元件之间的委托和调用接口藕
合而成，整个系统可由多个子模块藕合而成。各个元件（应该说各类，因为只要类
是好的，那么可认为各个元件也是好的）可单独测试，可以很方便的配置测试环
境，各个模块也可以这样测试，整个系统各模块之间只是简单遵守接口协议，并没
有真正的形成一个接口。

只是有一点很遗憾，由于JAVA本身的成功，编程被引导到继承体系中了，可能是因
为这个是最容易实现的吧，但并不是说它是最合理的体系，对python这样的动态语
言来说，使用继承我认为仅仅是长久形成的编程习惯，而不是最理想的。

最后举个简单例子，解释继承和委托之间的区别：

继承：
class 人：
def on肚子痛(self):
pass

class 穷人(人)：
def on肚子痛(self):
self.用手揉()

class 富人（人）：
def on肚子痛(self):
self.找医生()

委托（使用我写的那个delegate类）：
class 人：
def __init__(self):
self.on肚子痛 = deletate (proto='on肚子痛()')

def 找医生（）：
pass

def 用手揉（）：
pass

穷人 ＝ 人（）
富人 ＝ 人（）
穷人.on肚子痛 += 用手揉
副人.on肚子痛 += 找医生

从这里看，比继承好的一点是：穷人富人都是人，他们别的方面可能都一样，可以
细微调整某个不同的地方。

注：上面用的+=符号是迫不得已，因为不能直接用=。（如果用：穷人.on肚子痛 =
delegate(用手揉)也是可以的)

shhgs 写道:

>很遗憾，一个知音都没找到，不过我还是坚持我的看法。
>
>1。Interface很重要，它是解决Python多重继承和MRO问题的最佳途径。如果真的
向你们说的那样无聊，Zope和Twisted就不用费
>劲巴力地去搞一个了。
>
>2。自从用了Python，我就再也没有留恋过Perl。不过有一个小小的例外，就是在
写range(10) 的时候。我时常情不自禁地写for i 
>in [1..3]。此外Python没有提供enumeration，__range__也可以借此补上这个空
白。
>
>3。private，public，和friend。并不是他们不重要，而是Python的实现比较困
难。Python可以在对象的实例化之后再绑定方
>法，所以实现private有一定的难度。如果你把一个方法定义为private的，过一
会用户再绑定了一个同名的方法，请问这个方法到底算不算，怎么算。但是有难度
不是说没必要。否则Guido根本没必要去搞什么__XXX的方法名混淆。
>  
>
>-----------------------------------------------------------------------
>-
>
>_______________________________________________
>python-chinese list
>python-chinese at lists.python.cn 
>http://python.cn/mailman/listinfo/python-chinese
>  
>
_______________________________________________
python-chinese list
python-chinese at lists.python.cn
http://python.cn/mailman/listinfo/python-chinese

Interface恐怕不止是提供语言兼容吧，它所表达的抽象的中间层对于OOP的意义是
重大的，至于是否一定要用Interface来

表达这种抽象的中间层，我觉得倒未必，反正以现在而言，对我来说，Python中有
没有Interface都无所谓的，因为对我来说

它已足够动态和灵活。

 

 

 

-----邮件原件-----
发件人: python-chinese-bounces at lists.python.cn
[mailto:python-chinese-bounces at lists.python.cn] 代表 March Liu
发送时间: 2005年6月30日 8:52
收件人: shhgs; python-chinese at lists.python.cn
主题: Re: [python-chinese] 大家对PEP 3000有什么看法？

 

 

在05-6-30，shhgs <shhgs.efhilt at gmail.com> 写道：
为什么有Interface的情况下我就不用写委托？就算在C#下，我也经常用委托而不
是继承，过多使用继承会导致结构复杂笨重。有了车还要有船吗？要， 因为它们
的用途不同。在Java中也许继承更方便，但在Python中就未必了。何必要把Java中
那一套搬过来呢？每一种语言都有它的特色，应该正视。 Interface在我看来意义
无非是在CLI/Java这样的虚拟机环境下，和其它语言提供兼容。如果不在乎这种兼
容，没有它也没什么不可以。

很有意思。但是你写这个delegate不正说明interface的重要性吗？如果有了
interface你还要去写这个delegate吗？直接implement岂不是更方便？ 

其实某种功能，任何一种语言都能实现。C也可以OOP，但是有为什么它不能算是
OOP的语言呢？Python是用来帮助我们提高开发效率的，所以不是说这个东西
Python能实现，我们就不用加了。2.4加的那个Set就是例子。2.3之前我曾经自己
写过Set，但现在用标准类库的，不但性能高，用着也放心。

On 6/29/05, cpunion <cpunion at 263.net  cpunion at 263.net> > wrote:
> 这个其实是习惯的问题，C++没出来以前，大家用C是怎么做的？
>
> C++（或其类似的语言）形成习惯以后，很多东西就是觉得必然像C++才好，比如
> JAVA就是这样。
>
> JAVA在WEB上的应用形成习惯以后，大家也就觉得一定要写成某种形式的
> interfaces，才能扩展，这个也是习惯。
>
> 静态语言中interface是必须的，因为变量必须声明一个类型，而这个类型又要
能
> 表现出所操作对象的基本方法集合，于是就形成interface语法。
>
> 但动态语言中，这个不是必须的，如果认为这个是必须的，那就是从JAVA中带来
的
> 习惯，可以简单问一下：为何只有PYTHON应用到WEB领域后，才有人想起来需要
> interface?
>
> 再来解释一下，为何java中一定要interface，因为java只支持"面向对象"这一
种
> 编程范式，interface是在面向对象范式中用到的，所以是必须。而C++支持4种
以
> 上，python呢？比C++更多。
>
> interface只在继承体系中才有意义，如果我们不使用继承，那么interface就毫
无
> 意义了，其它的选择真的很多，我昨天在啄木鸟上发的一个委托功能的python实

> 现，其实也算一种解决方案（我只是简单模仿C#委托）。
>
> 一个系统可以全部采用委托来设计，可以把完全避免继承。采用委托来设计，可
以
> 拿电路板作比较：电路板上只有一些基本元素（电容、电阻、电感、二极管、三
极
> 管等等），可曾看到大规模的继承体系？各个元件的每个输入极就是一个调用接
> 口，每个输出极就是一个委托，一个子模块可由多个元件之间的委托和调用接口
藕 
> 合而成，整个系统可由多个子模块藕合而成。各个元件（应该说各类，因为只要
类
> 是好的，那么可认为各个元件也是好的）可单独测试，可以很方便的配置测试环
> 境，各个模块也可以这样测试，整个系统各模块之间只是简单遵守接口协议，并
没
> 有真正的形成一个接口。
>
> 只是有一点很遗憾，由于JAVA本身的成功，编程被引导到继承体系中了，可能是
因
> 为这个是最容易实现的吧，但并不是说它是最合理的体系，对python这样的动态
语 
> 言来说，使用继承我认为仅仅是长久形成的编程习惯，而不是最理想的。
>
> 最后举个简单例子，解释继承和委托之间的区别：
>
> 继承：
> class 人：
> def on肚子痛(self):
> pass
>
> class 穷人(人)：
> def on肚子痛(self):
> self.用手揉 ()
>
> class 富人（人）：
> def on肚子痛(self):
> self.找医生()
>
> 委托（使用我写的那个delegate类）：
> class 人：
> def __init__(self):
> self.on肚子痛 = deletate (proto='on肚子痛()')
>
> def 找医生（）： 
> pass
>
> def 用手揉（）：
> pass
>
> 穷人 ＝ 人（）
> 富人 ＝ 人（）
> 穷人.on肚子痛 += 用手揉
> 副人.on肚子痛 += 找医生
>
> 从这里看，比继承好的一点是：穷人富人都是人，他们别的方面可能都一样，可
以
> 细微调整某个不同的地方。
>
> 注：上面用的+=符号是迫不得已，因为不能直接用=。（如果用：穷人.on肚子痛
=
> delegate(用手揉)也是可以的)
>
> shhgs 写道:
>
> >很遗憾，一个知音都没找到，不过我还是坚持我的看法。
> >
> >1。Interface很重要，它是解决Python多重继承和MRO问题的最佳途径。如果真
的向你们说的那样无聊，Zope和Twisted就不用费劲巴力地去搞一个了。 
> >
> >2。自从用了Python，我就再也没有留恋过Perl。不过有一个小小的例外，就是
在写range(10) 的时候。我时常情不自禁地写for i
> >in [1..3]。此外Python没有提供enumeration，__range__也可以借此补上这个
空白。
> >
> >3。private，public，和friend。并不是他们不重要，而是Python的实现比较
困难。Python可以在对象的实例化之后再绑定方法，所以实现private有一定的难
度。如果你把一个方法定义为private的，过一会用户再绑定了一个同名的方法，
请问这个方法到底算不算，怎么算。但是有难度不是说没必要。否则Guido根本没
必要去搞什么__XXX的方法名混淆。 
> >
> >
>
>-----------------------------------------------------------------------
-
> >
> >_______________________________________________
> >python-chinese list
> > python-chinese at lists.python.cn
> >http://python.cn/mailman/listinfo/python-chinese
> >
> >
> _______________________________________________
> python-chinese list
> python-chinese at lists.python.cn
> http://python.cn/mailman/listinfo/python-chinese
>

_______________________________________________
python-chinese list
python-chinese at lists.python.cn 
http://python.cn/mailman/listinfo/python-chinese






-- 
欢迎访问：
http://blog.csdn.net/ccat  <http://blog.csdn.net/ccat> 

刘鑫
March.Liu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20050630/e3005b32/attachment.htm

有很多区别，如果有了interface，就我自己来讲一样要用delegate，它们面向的问题领域不同，甚至可以配合使用。interface是一组未实现的方法声明，而delegate可以作为其中一个未实现的方法。

继承是采用重写（重新实现）的方式来改变“一类”对象的行为（重写作用于interface就称为实现），一个有效的继承应该会实现所有 interface中定义的方法。

使用delegate则是明确地说“这个方法我不实现了”，通常也可以不实现，或者指定一定要它有一个实现，这里的实现和接口实现不同，它只需要调用约定一致。改变delegate的行为只会导致拥有这个delegate的对象的行为改变，所以实现一些“特例”就非常合适，但并不限制于此，如果把这个“特例”作为一个prototype，也可以把它看成一个类型了，采用clone的方式就可以得到和它一样的对象(s)[设计模式中的prototype]。

python这样的动态语言，实现interface的确有麻烦，zope的interface实现的也只是一个简单的“转型协议”，如果在语言层面上实现的话，应该会更理想，毕竟zope的interface使用起来并不是很爽，使用习惯不像其它语言的interface，多一种选择也不是坏事。

如果仅仅是因为名字问题，不想手工写__开头的名字，访问控制由编译器或解释器来做也是合理的要求，可以简单地把类定义里面的protected方法或属性加上__开头，外面调用自然就无法访问了，private则可以加上更复杂的名称混淆，让子类也无法访问到它。但这种方式也无法从根本上禁止别人调用，只要知道名字是如何处理的，就可以调用到，所以依旧只是个约定。

shhgs 写道:


>>很有意思。但是你写这个delegate不正说明interface的重要性吗？如果有了interface你还要去写这个delegate吗？直接implement岂不是更方便？
>>
>>其实某种功能，任何一种语言都能实现。C也可以OOP，但是有为什么它不能算是OOP的语言呢？Python是用来帮助我们提高开发效率的，所以不是说这个东西Python能实现，我们就不用加了。2.4加的那个Set就是例子。2.3之前我曾经自己写过Set，但现在用标准类库的，不但性能高，用着也放心。
>>
>>On 6/29/05, cpunion <cpunion at 263.net> wrote:
>>  
>>
>  
>
>>>>这个其实是习惯的问题，C++没出来以前，大家用C是怎么做的？
>>>>
>>>>C++（或其类似的语言）形成习惯以后，很多东西就是觉得必然像C++才好，比如
>>>>JAVA就是这样。
>>>>
>>>>JAVA在WEB上的应用形成习惯以后，大家也就觉得一定要写成某种形式的
>>>>interfaces，才能扩展，这个也是习惯。
>>>>
>>>>静态语言中interface是必须的，因为变量必须声明一个类型，而这个类型又要能
>>>>表现出所操作对象的基本方法集合，于是就形成interface语法。
>>>>
>>>>但动态语言中，这个不是必须的，如果认为这个是必须的，那就是从JAVA中带来的
>>>>习惯，可以简单问一下：为何只有PYTHON应用到WEB领域后，才有人想起来需要
>>>>interface?
>>>>
>>>>再来解释一下，为何java中一定要interface，因为java只支持"面向对象"这一种
>>>>编程范式，interface是在面向对象范式中用到的，所以是必须。而C++支持4种以
>>>>上，python呢？比C++更多。
>>>>
>>>>interface只在继承体系中才有意义，如果我们不使用继承，那么interface就毫无
>>>>意义了，其它的选择真的很多，我昨天在啄木鸟上发的一个委托功能的python实
>>>>现，其实也算一种解决方案（我只是简单模仿C#委托）。
>>>>
>>>>一个系统可以全部采用委托来设计，可以把完全避免继承。采用委托来设计，可以
>>>>拿电路板作比较：电路板上只有一些基本元素（电容、电阻、电感、二极管、三极
>>>>管等等），可曾看到大规模的继承体系？各个元件的每个输入极就是一个调用接
>>>>口，每个输出极就是一个委托，一个子模块可由多个元件之间的委托和调用接口藕
>>>>合而成，整个系统可由多个子模块藕合而成。各个元件（应该说各类，因为只要类
>>>>是好的，那么可认为各个元件也是好的）可单独测试，可以很方便的配置测试环
>>>>境，各个模块也可以这样测试，整个系统各模块之间只是简单遵守接口协议，并没
>>>>有真正的形成一个接口。
>>>>
>>>>只是有一点很遗憾，由于JAVA本身的成功，编程被引导到继承体系中了，可能是因
>>>>为这个是最容易实现的吧，但并不是说它是最合理的体系，对python这样的动态语
>>>>言来说，使用继承我认为仅仅是长久形成的编程习惯，而不是最理想的。
>>>>
>>>>最后举个简单例子，解释继承和委托之间的区别：
>>>>
>>>>继承：
>>>>class 人：
>>>>def on肚子痛(self):
>>>>pass
>>>>
>>>>class 穷人(人)：
>>>>def on肚子痛(self):
>>>>self.用手揉()
>>>>
>>>>class 富人（人）：
>>>>def on肚子痛(self):
>>>>self.找医生()
>>>>
>>>>委托（使用我写的那个delegate类）：
>>>>class 人：
>>>>def __init__(self):
>>>>self.on肚子痛 = deletate (proto='on肚子痛()')
>>>>
>>>>def 找医生（）：
>>>>pass
>>>>
>>>>def 用手揉（）：
>>>>pass
>>>>
>>>>穷人 ＝ 人（）
>>>>富人 ＝ 人（）
>>>>穷人.on肚子痛 += 用手揉
>>>>副人.on肚子痛 += 找医生
>>>>
>>>>从这里看，比继承好的一点是：穷人富人都是人，他们别的方面可能都一样，可以
>>>>细微调整某个不同的地方。
>>>>
>>>>注：上面用的+=符号是迫不得已，因为不能直接用=。（如果用：穷人.on肚子痛 =
>>>>delegate(用手揉)也是可以的)
>>>>
>>>>shhgs 写道:
>>>>
>>>>    
>>>>
>>    
>>
>>>>>>很遗憾，一个知音都没找到，不过我还是坚持我的看法。
>>>>>>
>>>>>>1。Interface很重要，它是解决Python多重继承和MRO问题的最佳途径。如果真的向你们说的那样无聊，Zope和Twisted就不用费劲巴力地去搞一个了。
>>>>>>
>>>>>>2。自从用了Python，我就再也没有留恋过Perl。不过有一个小小的例外，就是在写range(10) 的时候。我时常情不自禁地写for i
>>>>>>in [1..3]。此外Python没有提供enumeration，__range__也可以借此补上这个空白。
>>>>>>
>>>>>>3。private，public，和friend。并不是他们不重要，而是Python的实现比较困难。Python可以在对象的实例化之后再绑定方法，所以实现private有一定的难度。如果你把一个方法定义为private的，过一会用户再绑定了一个同名的方法，请问这个方法到底算不算，怎么算。但是有难度不是说没必要。否则Guido根本没必要去搞什么__XXX的方法名混淆。
>>>>>>
>>>>>>
>>>>>>------------------------------------------------------------------------
>>>>>>
>>>>>>_______________________________________________
>>>>>>python-chinese list
>>>>>>python-chinese at lists.python.cn
>>>>>>http://python.cn/mailman/listinfo/python-chinese
>>>>>>
>>>>>>
>>>>>>      
>>>>>>
>>>      
>>>
>>>>_______________________________________________
>>>>python-chinese list
>>>>python-chinese at lists.python.cn
>>>>http://python.cn/mailman/listinfo/python-chinese
>>>>
>>>>    
>>>>
>>>>------------------------------------------------------------------------
>>>>
>>>>_______________________________________________
>>>>python-chinese list
>>>>python-chinese at lists.python.cn
>>>>http://python.cn/mailman/listinfo/python-chinese
>>>>    
>>>>
>>    
>>

为什么到了zope等领域大家要强调实现Interface呢？
是因为OO和Design Pattern
zope twisted等frame work足够复杂所以会发现Interface在OO和Pattern的重要了
简单写些文本处理的脚本，甚至于OO都不用，所以没有Interface也无所谓的

在05-6-30，lifr <lifr_sh at yeah.net> 写道：
> 
> 我认为有没有interface不是一个习惯问题，而是在面向方法分析/设计中有它真正
> 的位置。
> 至于为什么，我建议可以看看"设计模式"里面的论述，里面说道了为什么要面向
> 接口编程。
> 更理论的东西我也没有看过。。。：）
> 
> 》》》可以简单问一下：为何只有PYTHON应用到WEB领域后，才有人想起来需要
> interface?
> 是的，做一些日常管理，文本分析之类的程序没人会抱怨python没有提供
> interface，
> 但在web领域，提出了interface的要求，why？
> 我认为更多的不是java遗留的习惯，而是领域本身对面向对象语言的自然要求。
> 
> 我是java过来的，我个人感觉对于多层的程序，自然会对interface提出要求。
> 所以，我觉得interface，访问控制是应该加入python的。
> 
> 
> -----Original Message-----
> From: python-chinese-bounces at lists.python.cn
> [mailto:python-chinese-bounces at lists.python.cn] On Behalf Of cpunion
> Sent: Wednesday, June 29, 2005 11:19 PM
> To: python-chinese at lists.python.cn
> Subject: Re: [python-chinese] 大家对PEP 3000有什么看法？
> 
> 这个其实是习惯的问题，C++没出来以前，大家用C是怎么做的？
> 
> C++（或其类似的语言）形成习惯以后，很多东西就是觉得必然像C++才好，比如
> JAVA就是这样。
> 
> JAVA在WEB上的应用形成习惯以后，大家也就觉得一定要写成某种形式的
> interfaces，才能扩展，这个也是习惯。
> 
> 静态语言中interface是必须的，因为变量必须声明一个类型，而这个类型又要能
> 表现出所操作对象的基本方法集合，于是就形成interface语法。
> 
> 但动态语言中，这个不是必须的，如果认为这个是必须的，那就是从JAVA中带来的
> 习惯，可以简单问一下：为何只有PYTHON应用到WEB领域后，才有人想起来需要
> interface?
> 
> 再来解释一下，为何java中一定要interface，因为java只支持"面向对象"这一
> 种
> 编程范式，interface是在面向对象范式中用到的，所以是必须。而C++支持4种以
> 上，python呢？比C++更多。
> 
> interface只在继承体系中才有意义，如果我们不使用继承，那么interface就毫无
> 意义了，其它的选择真的很多，我昨天在啄木鸟上发的一个委托功能的python实
> 现，其实也算一种解决方案（我只是简单模仿C#委托）。
> 
> 一个系统可以全部采用委托来设计，可以把完全避免继承。采用委托来设计，可以
> 拿电路板作比较：电路板上只有一些基本元素（电容、电阻、电感、二极管、三极
> 管等等），可曾看到大规模的继承体系？各个元件的每个输入极就是一个调用接
> 口，每个输出极就是一个委托，一个子模块可由多个元件之间的委托和调用接口藕
> 合而成，整个系统可由多个子模块藕合而成。各个元件（应该说各类，因为只要类
> 是好的，那么可认为各个元件也是好的）可单独测试，可以很方便的配置测试环
> 境，各个模块也可以这样测试，整个系统各模块之间只是简单遵守接口协议，并没
> 有真正的形成一个接口。
> 
> 只是有一点很遗憾，由于JAVA本身的成功，编程被引导到继承体系中了，可能是因
> 为这个是最容易实现的吧，但并不是说它是最合理的体系，对python这样的动态语
> 言来说，使用继承我认为仅仅是长久形成的编程习惯，而不是最理想的。
> 
> 最后举个简单例子，解释继承和委托之间的区别：
> 
> 继承：
> class 人：
> def on肚子痛(self):
> pass
> 
> class 穷人(人)：
> def on肚子痛(self):
> self.用手揉()
> 
> class 富人（人）：
> def on肚子痛(self):
> self.找医生()
> 
> 委托（使用我写的那个delegate类）：
> class 人：
> def __init__(self):
> self.on肚子痛 = deletate (proto='on肚子痛()')
> 
> def 找医生（）：
> pass
> 
> def 用手揉（）：
> pass
> 
> 穷人 ＝ 人（）
> 富人 ＝ 人（）
> 穷人.on肚子痛 += 用手揉
> 副人.on肚子痛 += 找医生
> 
> 从这里看，比继承好的一点是：穷人富人都是人，他们别的方面可能都一样，可以
> 细微调整某个不同的地方。
> 
> 注：上面用的+=符号是迫不得已，因为不能直接用=。（如果用：穷人.on肚子痛 =
> delegate(用手揉)也是可以的)
> 
> shhgs 写道:
> 
> >很遗憾，一个知音都没找到，不过我还是坚持我的看法。
> >
> >1。Interface很重要，它是解决Python多重继承和MRO问题的最佳途径。如果真的
> 向你们说的那样无聊，Zope和Twisted就不用费
> >劲巴力地去搞一个了。
> >
> >2。自从用了Python，我就再也没有留恋过Perl。不过有一个小小的例外，就是在
> 写range(10) 的时候。我时常情不自禁地写for i
> >in [1..3]。此外Python没有提供enumeration，__range__也可以借此补上这个空
> 白。
> >
> >3。private，public，和friend。并不是他们不重要，而是Python的实现比较困
> 难。Python可以在对象的实例化之后再绑定方
> >法，所以实现private有一定的难度。如果你把一个方法定义为private的，过一
> 会用户再绑定了一个同名的方法，请问这个方法到底算不算，怎么算。但是有难度
> 不是说没必要。否则Guido根本没必要去搞什么__XXX的方法名混淆。
> >
> >
> >-----------------------------------------------------------------------
> >-
> >
> >_______________________________________________
> >python-chinese list
> >python-chinese at lists.python.cn
> >http://python.cn/mailman/listinfo/python-chinese
> >
> >
> _______________________________________________
> python-chinese list
> python-chinese at lists.python.cn
> http://python.cn/mailman/listinfo/python-chinese
> 
> 
> _______________________________________________
> python-chinese list
> python-chinese at lists.python.cn
> http://python.cn/mailman/listinfo/python-chinese
> 
> 
> 


-- 
I'm the one, powered by nEO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20050630/2606764d/attachment.html

Interface这东西我在C#里也是经常用到的，应该说它在静态语言中提供了一个可靠的访问约定，这一点非常有意义，但对于Python这样的动态语 
言，是不是有必要加入呢？如果什么都看着好，Interface加进来，静态类型检查要不要加（类型检查其实Python有，只是不常用）？显式范型语法 
要不要加（其实动态语言天然就是泛型的，但是如果有人觉得不写

就不踏实呢）？还有诸如此类的很多问题，最后会不会变成VB那样不伦不类的 
东西？Python作为一门语言，向来是以简洁优雅著称的，一切的改动都不应该破坏这个特色，没有Interface，Python仍然是出色的语言，但 
加入太多流行的东西后，它会不会失去自己的个性？很多人选择Python，并不是因为它提供了其它语言也有的功能，而是因为它的与众不同。也许我的习惯和 
大家不太一样，如果需要强类型约束的地方，我更喜欢静态语言和动态语言混合编程，让每种技术都去做它擅长的事。
GOF的《设计模式》是本好书，我个人很喜欢，不过我一直认为与其背熟那些模式名字和范例，不如认真学习作者们如何分拆并解决问题。

在05-6-30，lifr <lifr_sh at yeah.net> 写道：
> 
> 我认为有没有interface不是一个习惯问题，而是在面向方法分析/设计中有它真正
> 的位置。
> 至于为什么，我建议可以看看"设计模式"里面的论述，里面说道了为什么要面向
> 接口编程。
> 更理论的东西我也没有看过。。。：）
> 
> 》》》可以简单问一下：为何只有PYTHON应用到WEB领域后，才有人想起来需要
> interface?
> 是的，做一些日常管理，文本分析之类的程序没人会抱怨python没有提供
> interface，
> 但在web领域，提出了interface的要求，why？
> 我认为更多的不是java遗留的习惯，而是领域本身对面向对象语言的自然要求。
> 
> 我是java过来的，我个人感觉对于多层的程序，自然会对interface提出要求。
> 所以，我觉得interface，访问控制是应该加入python的。
> 
> 
> -----Original Message-----
> From: python-chinese-bounces at lists.python.cn
> [mailto:python-chinese-bounces at lists.python.cn] On Behalf Of cpunion
> Sent: Wednesday, June 29, 2005 11:19 PM
> To: python-chinese at lists.python.cn
> Subject: Re: [python-chinese] 大家对PEP 3000有什么看法？
> 
> 这个其实是习惯的问题，C++没出来以前，大家用C是怎么做的？
> 
> C++（或其类似的语言）形成习惯以后，很多东西就是觉得必然像C++才好，比如
> JAVA就是这样。
> 
> JAVA在WEB上的应用形成习惯以后，大家也就觉得一定要写成某种形式的
> interfaces，才能扩展，这个也是习惯。
> 
> 静态语言中interface是必须的，因为变量必须声明一个类型，而这个类型又要能
> 表现出所操作对象的基本方法集合，于是就形成interface语法。
> 
> 但动态语言中，这个不是必须的，如果认为这个是必须的，那就是从JAVA中带来的
> 习惯，可以简单问一下：为何只有PYTHON应用到WEB领域后，才有人想起来需要
> interface?
> 
> 再来解释一下，为何java中一定要interface，因为java只支持"面向对象"这一
> 种
> 编程范式，interface是在面向对象范式中用到的，所以是必须。而C++支持4种以
> 上，python呢？比C++更多。
> 
> interface只在继承体系中才有意义，如果我们不使用继承，那么interface就毫无
> 意义了，其它的选择真的很多，我昨天在啄木鸟上发的一个委托功能的python实
> 现，其实也算一种解决方案（我只是简单模仿C#委托）。
> 
> 一个系统可以全部采用委托来设计，可以把完全避免继承。采用委托来设计，可以
> 拿电路板作比较：电路板上只有一些基本元素（电容、电阻、电感、二极管、三极
> 管等等），可曾看到大规模的继承体系？各个元件的每个输入极就是一个调用接
> 口，每个输出极就是一个委托，一个子模块可由多个元件之间的委托和调用接口藕
> 合而成，整个系统可由多个子模块藕合而成。各个元件（应该说各类，因为只要类
> 是好的，那么可认为各个元件也是好的）可单独测试，可以很方便的配置测试环
> 境，各个模块也可以这样测试，整个系统各模块之间只是简单遵守接口协议，并没
> 有真正的形成一个接口。
> 
> 只是有一点很遗憾，由于JAVA本身的成功，编程被引导到继承体系中了，可能是因
> 为这个是最容易实现的吧，但并不是说它是最合理的体系，对python这样的动态语
> 言来说，使用继承我认为仅仅是长久形成的编程习惯，而不是最理想的。
> 
> 最后举个简单例子，解释继承和委托之间的区别：
> 
> 继承：
> class 人：
> def on肚子痛(self):
> pass
> 
> class 穷人(人)：
> def on肚子痛(self):
> self.用手揉()
> 
> class 富人（人）：
> def on肚子痛(self):
> self.找医生()
> 
> 委托（使用我写的那个delegate类）：
> class 人：
> def __init__(self):
> self.on肚子痛 = deletate (proto='on肚子痛()')
> 
> def 找医生（）：
> pass
> 
> def 用手揉（）：
> pass
> 
> 穷人 ＝ 人（）
> 富人 ＝ 人（）
> 穷人.on肚子痛 += 用手揉
> 副人.on肚子痛 += 找医生
> 
> 从这里看，比继承好的一点是：穷人富人都是人，他们别的方面可能都一样，可以
> 细微调整某个不同的地方。
> 
> 注：上面用的+=符号是迫不得已，因为不能直接用=。（如果用：穷人.on肚子痛 =
> delegate(用手揉)也是可以的)
> 
> shhgs 写道:
> 
> >很遗憾，一个知音都没找到，不过我还是坚持我的看法。
> >
> >1。Interface很重要，它是解决Python多重继承和MRO问题的最佳途径。如果真的
> 向你们说的那样无聊，Zope和Twisted就不用费
> >劲巴力地去搞一个了。
> >
> >2。自从用了Python，我就再也没有留恋过Perl。不过有一个小小的例外，就是在
> 写range(10) 的时候。我时常情不自禁地写for i
> >in [1..3]。此外Python没有提供enumeration，__range__也可以借此补上这个空
> 白。
> >
> >3。private，public，和friend。并不是他们不重要，而是Python的实现比较困
> 难。Python可以在对象的实例化之后再绑定方
> >法，所以实现private有一定的难度。如果你把一个方法定义为private的，过一
> 会用户再绑定了一个同名的方法，请问这个方法到底算不算，怎么算。但是有难度
> 不是说没必要。否则Guido根本没必要去搞什么__XXX的方法名混淆。
> >
> >
> >-----------------------------------------------------------------------
> >-
> >
> >_______________________________________________
> >python-chinese list
> >python-chinese at lists.python.cn
> >http://python.cn/mailman/listinfo/python-chinese
> >
> >
> _______________________________________________
> python-chinese list
> python-chinese at lists.python.cn
> http://python.cn/mailman/listinfo/python-chinese
> 
> 
> _______________________________________________
> python-chinese list
> python-chinese at lists.python.cn
> http://python.cn/mailman/listinfo/python-chinese
> 
> 
> 


-- 
欢迎访问：
http://blog.csdn.net/ccat

刘鑫
March.Liu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20050630/85d21107/attachment.htm