IronPython的第八块鳞片

        当我在IronPython的Message Borad中提出了关于Dictionary的问题之后，Jim对这个问题作了回复，并且指出，将属于.NET的类型引入到IronPython，会带来不少的问题。随后，有另外一个朋友对是否应该引入.NET中的类型，提出了他自己的疑问：
Why does IronPython need the types in System.Collections at all? Why not just use the built-in Python types? If it uses both, that seems like an awful lot of redundancy and confusion.

P.S. If the answer is, "arguments to many .NET methods are of type Hashtable, ArrayList, etc.," why not pass a Python built-in, which would be converted to the needed type? e.g. pass a built-in dictionary when the function calls for a Hashtable(). Or an array when it wants an ArrayList. 

        在IronPython中为什么需要System.Collections中的类型呢？为什么不仅仅是使用Python的内建类型呢？如果两者都可以使用，将会造成很多的重复和混乱。
        如果两者并存的原因是在于很多.NET的方法使用了诸如Hashtable, ArrayList等类型的话，那么为什么不可以在函数调用的时候将这些类型转换成Python内建的类型呢？譬如，Hashtable转换成dictionary，ArrayList转换成数组等。

IronPython的老爸Jim则给出了以下的解答，真的很详细。

One story about why these are used in the implementation (this is how I first read the question): IronPython is a complete self-contained Python implementation. It doesn't use any of the C code from the standard Python implementation. This means that IronPython needs to contain its own implementations of all of the standard Python datatypes. Rather than create redundancy and confusion by completely reimplementing all of these standard datatypes, the existing System.Collection types are typically wrapped so that IronPython only needs to implement code to capture the relatively small differences in semantics between the Python containers and the .NET ones.

        关于为什么这些类型会在IronPython中使用的一个解答(这是我最初考虑这个问题的方式)：IronPython是一个完全独立的Python实现，它不会使用标准Python实现中的任何C代码。这就意味着IronPython需要自己去实现所有Python中的标准数据类型。如果完全从头实现这些标准数据类型，是会产生重复和混乱的。相反，如果使用了System.Collecion中的数据类型，对其进行封装，并且实现一些代码以转换Python与.NET之间在语义上的差别，则会最大程度上减少冗余和混乱。

A central goal of IronPython is to reuse as much of the underlying .NET infrastructure as possible while building a correct implementation of the Python language and core libraries. Smaller implementations are easier to develop and maintain. Moreover, this lets IronPython take advantage of improvements in the framework. There's great value in sharing this work across as many different languages as possible.

        IronPython的核心目标之一就是在建立一个Python语言的正确实现和核心Python类库的同时，尽可能重用.NET最根本的基础架构。 规模越小的实现则越容易开发和维护。而且，也可以让IronPython享受到.NET框架升级所带来的好处。尽可能多的不同语言共享这个框架会带来巨大的价值。

A different story about why Python programmers might see these (this should answer the question that I think is really being asked): Programmers writing code in IronPython will almost always work with the standard Python built-in datatypes. When possible, these are designed to interoperate well with .NET methods. In particular they can be passed to methods expecting interfaces like IEnumerable, IList or IDictionary.

        关于为什么这些类型会在IronPython中使用的另外一个解答(我想这个才是真正可以解答问题的)：那些使用IronPython来写代码的程序员几乎都是和标准Python的内建数据类型打交道的，因此，如果有可能，这些内建数据类型都被设计成可以与.NET方法实现良好的协作(注：也就是说，如果你的一个.NET的方法需要的是一个Hashtable的参数，你构造了一个Dictionary传入这个方法也是OK的，这样的话，就不需要把Hashtable摆出来了，呵呵～～)。特别地，这些内建数据类型可以被当作接口类型传入方法，譬如当作IEnumerable，IList或者IDictionary接口。

There are still places where IronPython programmers might encounter these datatypes when working with .NET classes. One is when a .NET method returns a Hashtable, should that be automatically converted to a Python dictionary? That could be a very expensive operation depending on the size of the dictionary. This same issue of the cost of conversions can apply to methods that accept a concrete type rather than an interface. Another case is where there are CLR types that provide functionality that isn't easily availabe with the standard Python built-ins. The TreeDictionary in .NET 2.0 is a simple example of this. For the case where you want an efficient dictionary that is maintained in an ordered sorted by keys, then this could be appealing to the Python programmer. The goal is to figure out how to support these kinds of scenarios with the least confusion.

        当你使用.NET类的时候，仍然会有很多机会碰到这些.NET的数据类型。一种情况是当一个.NET的方法返回一个Hashtable，是否应该将其自动转换为Dictionary类型呢？随着dicionary的容量变大，这个转换过程将会是很耗资源的操作。当一个方法接受一个具体类型而不是一个接口作参数的情况下，这样的问题也会出现；另外一种情况是利用标准Python的内建数据类型去实现CLR中一些类型提供的功能存在较大的困难。.NET 2.0中的TreeDictionary就是一个简单的例子。对于这种情况，你需要一个有效的dictionary，它本身是有序的，可以通过key去排序(注：在Python中，dictionary是无序的)，而这个将会吸引Python程序员。总之，引入.NET的类型，会让Python程序员感到迷惑，如何在实现以上所说的这些情形下，将混淆的可能性降至最小就是我们需要解决的问题了。