2006年11月13日 星期一 15:15
在Python的whatsnew里面提到Partial Function Application时有下面的代码 import functools def log (message, subsystem): "Write the contents of 'message' to the specified subsystem." print '%s: %s' % (subsystem, message) ... server_log = functools.partial(log, subsystem='server') server_log('Unable to open socket') 看起来和FP中的High-Order Function很像, 也返回一个Curry化的函数. 它们是一回事吗? Thanks.
2006年11月14日 星期二 09:05
在Python的whatsnew里面提到Partial Function Application时有下面的代码 import functools def log (message, subsystem): "Write the contents of 'message' to the specified subsystem." print '%s: %s' % (subsystem, message) ... server_log = functools.partial(log, subsystem='server') server_log('Unable to open socket') 看起来和FP中的High-Order Function很像, 也返回一个Curry化的函数. 它们是一回事吗? Thanks.
2006年11月14日 星期二 09:21
On 11/14/06, Julius F. Huang <fozzold在gmail.com> wrote: > 在Python的whatsnew里面提到Partial Function Application时有下面的代码 > import functools > def log (message, subsystem): > "Write the contents of 'message' to the specified subsystem." > print '%s: %s' % (subsystem, message) > ... > server_log = functools.partial(log, subsystem='server') > server_log('Unable to open socket') > > 看起来和FP中的High-Order Function很像, 也返回一个Curry化的函数. > 它们是一回事吗? > > Thanks. 不懂High-Order Function可能差不多吧。 -- I like python! UliPad <>: http://wiki.woodpecker.org.cn/moin/UliPad My Blog: http://www.donews.net/limodou
2006年11月14日 星期二 09:51
我有一个疑问: 函数应该是只处理数据的过程, 但是decorator好像可以(改变/生成)函数的内部特性, 而这些特性是通过函数的数据属性(我不知道可不可以这么叫)来保存的, 我觉得这个和C++的functor的想法接近, 但是在C++里, functor是类, 那反过来想, 在python里面, 现在的class 和 decoratored function是不是在功能上有些重复呢? 也就是说, decoratored function有什么特性是单纯的class不能完成的呢? 我接触python有段时间了, 不过这些高级特性还用得不多, 有错误的地方大家多指教. 还有, 最近的python感觉好像在走c++走过的路, 就是添加很多新特性来完成新功能, 带出很多新语法, 发现不足, 总结一下下次又加入很多新东西. 但是给我的感觉是在打补丁, 有很多新特性是为了弥补旧语法的限制. 我记得有这样的说法: 没有语言是生来完美的, 语言应该在发展中逐步去掉旧的限制, 而不是不断的加入新东西来绕过那些旧的缺陷. 另外python的一些新语法像是"语法糖", 我个人觉得有些冗余. 是不是在简洁强大的核心语法上用大家约定俗成的一些写法来表达会好些? 这只是个人的一些想法, 大家多批评, 这样我才能更了解python, 谢谢! :)
2006年11月14日 星期二 10:17
On 11/14/06, Julius F. Huang <fozzold在gmail.com> wrote: > 我有一个疑问: > 函数应该是只处理数据的过程, 但是decorator好像可以(改变/生成)函数的内部特性, > 而这些特性是通过函数的数据属性(我不知道可不可以这么叫)来保存的, 我觉得这个和C++的functor的想法接近, 但是在C++里, > functor是类, 那反过来想, 在python里面, 现在的class 和 decoratored > function是不是在功能上有些重复呢? 也就是说, decoratored function有什么特性是单纯的class不能完成的呢? class function 在python中都是对象。而decorator的作用相当于在原有函数的基本上创建一个新的对象。但它并不能真正改变原函数的内部处理,它能做的只是在原函数的处理前或处理后增加新的处理,或者改变原函数的一些参数。要知道,这些参数在python中也是可以得到的。不知你是否了解过java中的aop(而向方面的编程),就是类似的东西。对于Partial function它的主要功能是例用decorator来修改原函数的参数,从而构建了一个新的函数,但可以使用更少的参数去调用原函数。 > > 我接触python有段时间了, 不过这些高级特性还用得不多, 有错误的地方大家多指教. > > 还有, 最近的python感觉好像在走c++走过的路, 就是添加很多新特性来完成新功能, 带出很多新语法, 发现不足, > 总结一下下次又加入很多新东西. 但是给我的感觉是在打补丁, 有很多新特性是为了弥补旧语法的限制. > 我记得有这样的说法: > 没有语言是生来完美的, 语言应该在发展中逐步去掉旧的限制, 而不是不断的加入新东西来绕过那些旧的缺陷. 语言总是在发展的,修改旧的东西会造成大量的不兼容,因此增加新特性是比较好的解决方式。当然目前来说我还没有对哪些是不好的东西有太多的感受,不知你能否举出一两个例子来。而许多增加都是因为有新的需要,如yield的改变。它其实将原来语句的方式改为了表达式的方式,其实就是在原有旧语法的基础上进行了扩充,但同时这种变化并没有对原来的使用造成兼容性的问题。还有象generator表达式的用法,这是新的,但它并不是list comphrehension 的替换,作用不同。还有象with的用法,这完全是新的东西。对于python来说,你并不一定要了解新东西之后才可以编程,新东西可以不用,因为有替换的方式。只不过使用新东西在某些情况下更方便而已。其它语言的新特性我想也差不多,它们应该随着编程人员水平的上升而逐渐使用。 > > 另外python的一些新语法像是"语法糖", 我个人觉得有些冗余. 是不是在简洁强大的核心语法上用大家约定俗成的一些写法来表达会好些? 其实你的约定俗成的想法正好是pythonic的思想的一条体现: 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! There should be one-- and preferably only one --obvious way to do it. 当然,虽然如此,但仍然还有许多的事情不止一条路,这个就希望让程序尽量的采用python的习惯,尽量的清晰,不要过多的讲究代码的简洁。 > > 这只是个人的一些想法, 大家多批评, 这样我才能更了解python, 谢谢! > :) 多交流。 -- I like python! UliPad <>: http://wiki.woodpecker.org.cn/moin/UliPad My Blog: http://www.donews.net/limodou
2006年11月14日 星期二 11:04
On 11/14/06, limodou <limodou在gmail.com> wrote: > class function 在python中都是对象。而decorator的作用相当于在原有函数的基本上创建一个新的对象。但它并不能真正改变原函数的内部处理,它能做的只是在原函数的处理前或处理后增加新的处理,或者改变原函数的一些参数。要知道,这些参数在python中也是可以得到的。不知你是否了解过java中的aop(而向方面的编程),就是类似的东西。 哦, 现在decorator给我的感觉更像Eiffel的前置/后置声明了, :) 其实我的意思是class和function在python中都是对象, 现在function也可以有自己的状态, 那和class有什么区别吗? 我试了试, function的状态是由外部给的, 在function里面无法知道自己有哪些状态, 假设我没试错, 从这个方面看还没有class来得有用呢. list comprehension和generator的作用有哪些区别呢? 我觉得如果只是list comprehension可以生成list的话, list(generator expression)也可以啊. 当然我见过有人提到list comprehension的变量外部可以用到, 不过我没明白, 希望limodou大大指点, :) 如果iterator的方式遍布python的话, 用generator代替list comprehension有什么问题? 还有with的用法, (有很多疑问, 需要解决, :P) 在ruby里面, block就可以做到一些with要干的事, 比如 in python: with open('/etc/passwd', 'r') as f: for line in f: print line 可以保证文件被关闭. in ruby: class File def File.open_and_process(*args) f = File.open(*args) yield f f.close() end end File.open_and_process("/etc/passwd", "r") do |file| while line = file.gets puts line end end 也保证文件被关闭. 当然ruby的例子是我从书里抄来的, 没考虑exception的问题, 而且比python的长多了, 只是这种用法很让人舒服, :) block是在ruby里面一直就有的很重要的用法, 而python需要加入新的statement来简洁的表达, 所以我觉得像"语法糖". 我的这些认识都是看pep和文档得来的, 不充分, 但是我周围没有用python的人, 一个人摸太慢, 所以就直接发到maillist了, 不是鼓吹其他语言的狂热份子, 只是对语言本身感兴趣. >对于python来说,你并不一定要了解新东西之后才可以编程,新东西可以不用,因为有替换的方式。只不过使用新东西在某些情况下更方便而已。其它语言的新特性我想也差不多,它们应该随着编程人员水平的上升而逐渐使用。 > 当然,虽然如此,但仍然还有许多的事情不止一条路,这个就希望让程序尽量的采用python的习惯,尽量的清晰,不要过多的讲究代码的简洁。 > 嗯, 是的, 我完全赞同你, 明天我要给公司上python的培训课, 希望能多让人了解python, 使用python. 当然也希望展现python的优点, 不被人问倒, :P
2006年11月14日 星期二 11:33
On 11/14/06, Julius F. Huang <fozzold在gmail.com> wrote: > On 11/14/06, limodou <limodou在gmail.com> wrote: > > class function 在python中都是对象。而decorator的作用相当于在原有函数的基本上创建一个新的对象。但它并不能真正改变原函数的内部处理,它能做的只是在原函数的处理前或处理后增加新的处理,或者改变原函数的一些参数。要知道,这些参数在python中也是可以得到的。不知你是否了解过java中的aop(而向方面的编程),就是类似的东西。 > > 哦, 现在decorator给我的感觉更像Eiffel的前置/后置声明了, :) > 其实我的意思是class和function在python中都是对象, 现在function也可以有自己的状态, 那和class有什么区别吗? > 我试了试, function的状态是由外部给的, 在function里面无法知道自己有哪些状态, 假设我没试错, > 从这个方面看还没有class来得有用呢. 它们的作用不同。因此处理上不同。对于class当然更强大,可以派生,可以覆盖。而function没有。之所以有decorator,是因为有些处理可以希望不改变原function的基础上做其它的一些事情,比如记日志,用户认证,同步处理。这些东西当然可以直接在function中加入,但是必然要修改代码。采用decorator就可以不改变原函数的方法了,而且增加,删除额外的功能都很方便。而你所说的状态又是指什么,为什么funtion要知道自已的状态。如果你的处理需要过多的关心自已的状态,那么你就要写成class。function就是一个处理,一个加工。传入参数,输出结果。而class是一个实体,它的功能要强得多。在面向对象中,并不所有东西都要使用对象来处理,仍然有一些是流程,是过程,这些东西没有必要,也不可能完全使用面向对象来表示。function只是一个过程处理而已。因此它只需要关心外部的参数,并不需要去刻意维护什么状态,维护状态应该是对象,或其它什么东西的事情。 我是这样理解的。 > > > list comprehension和generator的作用有哪些区别呢? > 我觉得如果只是list comprehension可以生成list的话, list(generator expression)也可以啊. > 当然我见过有人提到list comprehension的变量外部可以用到, 不过我没明白, 希望limodou大大指点, :) > 如果iterator的方式遍布python的话, 用generator代替list comprehension有什么问题? > list comprehension是一次生成所有的结果。generator是一次只生成一个结果,在内存消耗上和执和效率上要高。list(generator expression)这样的效率低。替换的话要看具体的应用。有时你的确希望得到一个完整的结果,有时你需要在循环中处理。因此场合不同,使用也不同。 > > 还有with的用法, (有很多疑问, 需要解决, :P) > 在ruby里面, block就可以做到一些with要干的事, 比如 > in python: > with open('/etc/passwd', 'r') as f: > for line in f: > print line > 可以保证文件被关闭. > in ruby: > class File > def File.open_and_process(*args) > f = File.open(*args) > yield f > f.close() > end > end > File.open_and_process("/etc/passwd", "r") do |file| > while line = file.gets > puts line > end > end > 也保证文件被关闭. > 当然ruby的例子是我从书里抄来的, 没考虑exception的问题, 而且比python的长多了, 只是这种用法很让人舒服, :) > block是在ruby里面一直就有的很重要的用法, 而python需要加入新的statement来简洁的表达, 所以我觉得像"语法糖". > with我没有什么研究,只知道它可以在某些情况化做一些保护。因为我还用不上,所以也不太关心是不是语法糖。正象我前面的邮件说的,并不是很个新特性你只有掌握了才可以去编程,在更多的时候,一些新特性也许你不去学,可能永远也用不到。比如new style class,你不学,不知道,也不会有什么关系。而ruby的block虽然python,没有,我也并没有觉得少了它有什么关系。python有自已的方式,ruby也有自已的方式。也许有些特性会融合,但并不是非有不可。我也的确没有体会到block会给python带来什么好处,等有了再说吧。 而且从个人角度来说,我看过一段ruby,我实在是对它提不起兴趣,因为python已经让我无法对其它的语言产生兴趣,更何况ruby的语法并不比python的好读。 > > 我的这些认识都是看pep和文档得来的, 不充分, 但是我周围没有用python的人, 一个人摸太慢, 所以就直接发到maillist了, > 不是鼓吹其他语言的狂热份子, 只是对语言本身感兴趣. 个人有自已的喜好很正常,也可以讨论。 > -- I like python! UliPad <>: http://wiki.woodpecker.org.cn/moin/UliPad My Blog: http://www.donews.net/limodou
2006年11月14日 星期二 13:18
Great! 谢谢limodou的指点. 我比较喜欢看到语言的内在的一致性, 所以看到python的特性越来越多, 有些找不着北, 才有了不少问题. 现在回头看看python的定位, 易用是很中心的一点, 它背后的细节大多数人都不会去深究, 所以我过于关注语法的干净是有些偏颇, :) 就着这个帖子问问, python的web framework那么多, 作为一个web开发的新手, 我该从那方面入手呢? WSGI在web开发中处于什么位置? 最近想作这方面的事, 看到ruby很热, 而python好像没有太多动静, 希望大家多多指点. 我是在web方面是纯新手, 现在在看HTML/CSS的书. 在C/C++和Unix方面已经有些年头了, 不是新手, :) Thanks!
2006年11月14日 星期二 13:40
On 11/14/06, Julius F. Huang <fozzold在gmail.com> wrote: > Great! > > 谢谢limodou的指点. > 我比较喜欢看到语言的内在的一致性, 所以看到python的特性越来越多, 有些找不着北, 才有了不少问题. 现在回头看看python的定位, > 易用是很中心的一点, 它背后的细节大多数人都不会去深究, 所以我过于关注语法的干净是有些偏颇, :) 不错。其实关于复杂度有一个blog: http://laurentszyster.be/blog/jruby-vs-cpython/ 上面有java, ruby, c, python的语法图表示,可以看到c, python相比java, ruby要简洁多了。 > > 就着这个帖子问问, python的web framework那么多, 作为一个web开发的新手, 我该从那方面入手呢? > WSGI在web开发中处于什么位置? 最近想作这方面的事, 看到ruby很热, 而python好像没有太多动静, 希望大家多多指点. > 我是在web方面是纯新手, 现在在看HTML/CSS的书. 在C/C++和Unix方面已经有些年头了, 不是新手, :) > 我个人的建议是从简至难,可以从 Karrigell 入手,然后进入 Django, turbogears, pylons,有兴趣再进入zope/plone。 不过最近想不管是哪一个入门容易,但深入难。许多东西只有形成自已的知识库才会运行纯熟,但知识库的建立不是一蹴而就的事。只有深入下去,不停地积累才有成果。而且随着发展,许多知识还需要更新。 wsgi 相对于web framework是处于比较底层的东西,它更多面向于创造框架的人,而不是使用框架的人。Django, TurboGears, Pylons都支持wsgi接口,但是pylons是完全使用wsgi和paste构建了。而django只是实现了wsgi的标准,其它的都是自已的。 RoR热在时机、宣传、以及一些特性上的确占据了优势。而且它关注于web开发,力量集中。而python没有一个集中的力量来完成类似的东西,django, TurboGears, Pylons都晚于ror,所以没有抢占先机。当然最主要是的一些观点的提出也是RoR先有的,所以RoR可以是rails开发的鼻祖。其实象zope出现更早,但是它在开发上相对复杂,所以一直火不起来,但功能上应该是非常强大的。而且python整个社区相对低调,从来没有发出过"java将死"之类的言论,使得大家认为python不构成很大的危胁。再加上python程序员喜欢各自为政,所以框架是不少,有影响的不多。同时还由于python在各领域都有应用,使得它在某一方面不是特别突出,而是全面开花。对于web的重视也是近年来才有更多的关注。不过不管怎么说,python在许多方便都是很强的。有一篇blog是讲述一个ruby爱好者如何因为ruby第三方库缺乏而转到python的阵营的,有兴趣可以看一看。 http://jesusphreak.infogami.com/blog/why_py -- I like python! UliPad <>: http://wiki.woodpecker.org.cn/moin/UliPad My Blog: http://www.donews.net/limodou
2006年11月14日 星期二 13:57
On 11/14/06, limodou <limodou在gmail.com> wrote: >一个ruby爱好者如何因为ruby第三方库缺乏而转到python的阵营的。 是的, 除了C, 好像还没有那种语言在第三方库的数量,质量和易用性上比的上python, 好像还得算上perl, :) 我记得limodou你好像说过Django的某个版本变化中它自身代码更改很大, 我就是有点担心这个, 框架本身应该在深入的考虑和几个原型实现后决定实现方法, 如果框架本身老在改, 应用就不好办了. pylons好像和我的喜好接近, 是在几个基本文件的基础上实现web应用的流程, 如何扩展就是应用的事了. 不知道我了解得对不对?
2006年11月14日 星期二 14:02
On 11/14/06, Julius F. Huang <fozzold在gmail.com> wrote: > On 11/14/06, limodou <limodou在gmail.com> wrote: > >一个ruby爱好者如何因为ruby第三方库缺乏而转到python的阵营的。 > > 是的, 除了C, 好像还没有那种语言在第三方库的数量,质量和易用性上比的上python, 好像还得算上perl, :) > > > 我记得limodou你好像说过Django的某个版本变化中它自身代码更改很大, 我就是有点担心这个, > 框架本身应该在深入的考虑和几个原型实现后决定实现方法, 如果框架本身老在改, 应用就不好办了. 只有在0.91-->0.95时变化大,其它的基本上没有什么变化了。我想任何一个项目不在万不得以的情况下是不会轻易改变 api 的。 > > pylons好像和我的喜好接近, 是在几个基本文件的基础上实现web应用的流程, 如何扩展就是应用的事了. 不知道我了解得对不对? pylons我了解不多。这是个人品味的问题了。对我来说我更喜欢django的方式,在使用上更简单一些。不过你喜欢哪个就是你的事了 :) -- I like python! UliPad <>: http://wiki.woodpecker.org.cn/moin/UliPad My Blog: http://www.donews.net/limodou
2006年11月14日 星期二 14:06
好的, 谢谢limodou, django和pylons我都会去尝尝, :)
2006年11月16日 星期四 13:45
感谢你们俩,我自己都提不出问题。 On 11/14/06, Julius F. Huang <fozzold在gmail.com> wrote: > > 好的, 谢谢limodou, django和pylons我都会去尝尝, :) > _______________________________________________ > python-chinese > Post: send python-chinese在lists.python.cn > Subscribe: send subscribe to python-chinese-request在lists.python.cn > Unsubscribe: send unsubscribe to python-chinese-request在lists.python.cn > Detail Info: http://python.cn/mailman/listinfo/python-chinese -------------- 下一部分 -------------- 一个HTML附件被移除... URL: http://python.cn/pipermail/python-chinese/attachments/20061116/9b0bd4d3/attachment.htm
Zeuux © 2025
京ICP备05028076号