posts - 256, comments - 1319, trackbacks - 41, articles - 8
  博客园 :: 首页 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理

IronPython的第二块鳞片

Posted on 2004-09-15 23:54 FantasySoft 阅读(1239) 评论(9)  编辑 收藏 所属分类: All About SoftSharp IronPython

        今天花了两个小时的时间把users-ironpython.com Archives中8月份的Mail仔细的看了一遍,整体的感觉就是IronPython这条小蟒蛇真的太幼小了,确实需要一段很长的时间才能成长起来。当然,我们可以从它的主人Jim的Mail中体会到他抚养这条小蟒蛇所承受的压力以及他的决心。
        8月份的Mail长达3900多行,在这些Mail当中,有提问的,有but report,有对IronPython开发的建议,也有对IronPython存在意义的怀疑。现将这些Mail中的一些精华部分列举如下,当做我摸索到的IronPython第二块鳞片吧:
        1、首先一个重要的问题就是跟CPython的兼容性问题,由于IronPython使用C#实现的,那么里面使用到的自定义的module,如"Equals"和"GetHashCode",是否需要呈现给开发人员呢?同时,象list这种原来内建的对象也拥有了更多的方法,如标准的list只能使用append方法去增加list中的元素,但是IronPython增加了C#下面实现的方法:Add(object)。有开发人员针对这个问题提出了自己的疑问,而Jim所给的回答就是,因为IronPython是在一个全新的平台去实现Python,与CPython完全保持一致是不可能,即使CPython本身版本的变迁也会带来变化;
        2、IronPython现在存在的一些比较严重的Bug,一个就是在上一篇blog中提到的第四点,关于使用__main__方法抛出的<eof>异常;一个是关于类成员访问的问题,如以下代码所示:

class Buggy: 
   class_member 
= 'find bug'
 
   def printMember(self):
       print Buggy.class_member

=
 Buggy()
t.printMember()  

        这段代码存为一个.py文件,然后使用IronPythonConsole来执行,结果会抛出Unhandled Exception: IronPython.Objects.PythonAttributeError,而这段代码在CPython下是运行OK的。
        3、很多热心的开发人员都提出了需要一个subversion repository来存放IronPython的代码,大家都可以为IronPython的开发作出一份努力,同时也可以得到IronPython最新的代码。譬如上面提出的两个bug,已经有程序员找出了修改的办法,但是就是苦于没有地方提交他们的代码。而Jim给出的回应是,由于他加入了微软,为了新的工作还需要搬家,他也很诚恳的请求大家耐心等他一段时间,因为他需要做个计划。同时,他也回应了在开发上的一些怀疑:I have great confidence the resulting plan will be one that will make the developer community happy.  If the plan doesn't work for developers,then it just doesn't make sense;
        4、一位热心的开发人员开发出了一个将Visual Studio中开发的基于C#的Form代码转化为IronPython代码的工具,我还没有来得及去尝试,但是看回复的Mail,应该做得不错,有兴趣的朋友可以下载来试一下;
        5、当使用IronPythonConsole命令行的方式去执行一个.py文件的时候,会在IronPythonConsole所在的目录bin下面产生一个__main__.exe文件,但是这样产生可执行文件的方式并非是在IronPython.com首页上提到的static compilation。事实上在0.6版本中并没有真正实现这个特性。
        总结就到这里了,有兴趣的朋友,可以访问IronPython的邮件列表,以获得更详细的信息。 

Feedback

#1楼    回复  引用  查看    

2004-09-16 08:37 by Cure      
很棒的文章,期待下篇:)
我觉得如果用IronPython来作C#或VB.net本来就可以作得很好的事,意义就不是很大了,在.net平台上找到Python自己的位置,对其它语言形成一个好的补充,才是IronPython的出路。

#2楼    回复  引用  查看    

2004-09-16 08:55 by 灵感之源      
用C#写Python,我觉得如果它不能在其独特的动态语言的基础上再挖掘潜力,似乎前途堪虞。

#3楼    回复  引用  查看    

2004-09-16 09:39 by FantasySoft      
大家应该会知道Zope社区的Python For .Net吧?如果单纯从表面上去看与CLR协作的情况,或许有些朋友会觉得IronPython在重复Python For .Net的工作。因为利用两者去写一个WinForm程序,几乎是没有太大的区别的。
然而正如它们各自文档所提到的,Python For .Net并不是CLR的first class language,因为它不会产生IL,它只是一个桥梁,将原来的CPython和CLR集成在一起,让CPython可以利用CLR的类库;而IronPython的目标则是让Python成为first class language,让它和C#,VB.NET有着同样的地位,因此它在运行的过程中生成IL的。

我想,现在最吸引我的就是生成IL这个部分,或许得花很长的时间去阅读代码了。

至于Python在.NET上的前途,我是很看好的,因为.NET的出现,managed code的出现,让开发效率得到了极大的提高,而Python在开发效率更是令人瞩目的。这样的强强联合,无疑会让开发效率达到一个前所未有的高度。

#4楼    回复  引用  查看    

2004-09-16 09:51 by FantasySoft      
谢谢Cure的鼓励!还请多多指教。//bow

#5楼    回复  引用  查看    

2004-09-16 10:17 by Cure      
如果生成IL代码,在效率上能够和C#的看齐,加上代码量要少的多,那Ironython实在是一个非常非常吸引人的东西,呵呵

#6楼    回复  引用  查看    

2004-09-16 10:44 by FantasySoft      
如果使用到Jim提及的static compilation的话,那么在执行效率上跟接近C#甚至与之持平应该是没有问题的。另外一个项目Boo也提到了执行效率的问题。

但是我们从另外一个角度去看待执行效率的问题,事实上,提高了开发效率,执行效率就会相应受到影响。不可否认,ASM执行效率是最高的,但是它的开发效率呢?我想在这个追求实效的年代,硬件成本逐渐降低的年代,开发效率则是最为重要的。

#7楼    回复  引用  查看    

2004-09-17 09:11 by Cure      
开发效率和执行效率的关系,我还是把执行效率放在第一位,开发效率是对程序员有益,但是软件最终是给客户用的,应该在客户可以接受的执行效率的前提下来提高开发效率。

有些偏题了,呵呵^_^

#8楼    回复  引用  查看    

2004-09-17 09:29 by FantasySoft      
Cure老大,用户确实会期待软件的执行效率会高一点了,但是他们更关注在自己的需求提出来以后的多长时间内能够看到软件的身影。所以双方在签定合同的时候,都会很关注开发软件的期限,如果延迟了,赔偿也是不小的。
为了能够按时完成用户提出来的需求,开发效率的提高是十分重要的。

#9楼    回复  引用    

2007-08-15 14:38 by kernel1983 [未注册用户]
我做了一些尝试,在ironpython中附带的一些例子上,的确得到了一些非常令人激动人心的结果

但是,当我开始使用IP做一些实际的事情的时候,我发现有很大的困难

在python中的基本数据类型str和int,虽然str已经对应了System.String, 但是有些.Net的库需要接受Array类型的Byte

int对应的Int16,UInt16,Int32,Int64
str与Byte,Char类型的转换

如果这些都需要我们自己来做的话,那太可怕了

标题  
姓名  
主页
Email (只有博主才能看到) 
验证码 *  看不清,换一张 [登录][注册]
内容(请不要发表任何与政治相关的内容)  
  登录  使用高级评论  新用户注册  返回页首  恢复上次提交      
该文被作者在 2004-10-14 17:09 编辑过
 
另存  打印