原文地址：http://blog.csdn.net/lalalalala/article/details/1773914
IronPython与CPython的不同之处
Information in this document is subject to change without notice. The example companies, organizations, products, people, and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarked, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
© Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, MS, Windows, Windows NT, MSDN, Active Directory, BizTalk, SQL Server, SharePoint, Outlook, PowerPoint, FrontPage, Visual Basic, Visual C++, Visual J++, Visual InterDev, Visual SourceSafe, Visual C#, Visual J#, and Visual Studio are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries.
Other product and company names herein may be the trademarks of their respective owners.
1
Overview（概述）
2
Standard Types, Functions, and Behaviors（标准类型，函数与行为）
3
Regular Expressions（正则表达式）
4
Extension Modules（扩展模块）
5
Interpreter and Environment（解释器与环境）
6
Garbage Collection（内存回收）
1 Overview 概述
CPython (the standard for Python) and IronPython are two different implementations of the Python language. While a
Language Reference exists for the Python language, there are a number of features of the language that are incompletely specified. The following lists all known differences between the two implementations of the Python language. These differences range from the trivial (such as, IronPython has different error messages in some cases, but raises the same exception type) to the significant (such as, IronPython does not implement some standard extension modules like cmath).
CPython（标准Python）与IronPython是Python语言的两种不同实现。鉴于有Python的语言参考，一些细节特性这里就不再复述了。下面将要列出的是这两种实现之间一些众所周知的不同之处，从细微的差异（比如IronPython有时在处理相同异常类型时会产生不同的错误信息）到显著的区别（比如IronPython没有实现一些如cmath这样的标准扩展库）都包括在内。
Any other differences not listed here are purely accidental omissions. Please submit a bug report at
www.codeplex.com/ironpython so that we can either fix the difference or update this document until we can fix it.
The IronPython team is very concerned about compatibility with CPython, and we plan to fix all incompatibilities that are not acceptable. Some incompatibilities (for example, those due to garbage collection implementation) are officially acceptable. We determined this by discussing these issues with the Python community. In some other cases, the CPython test suite needs to be updated where it makes inappropriate assumptions about implementation characteristics.
IronPython项目组非常关心与CPython的兼容性，并打算修正所有无法容忍的不兼容问题。从我们的角度有些不兼容问题（比如内存回收实现相关的问题）是可以容忍的。我们决定这样做是因为我们曾经和Python社区讨论过这些问题。而其他情况下，如果CPython测试用例集对实现特性做了不恰当的假设则需要更新它。
This list has been updated to describe the differences between IronPython 1.0 and CPython 2.4.3.
这个列表已经被更新过，可以说明IronPython1.0和CPython2.4.3之间的区别。
2 Standard Types, Functions and Behaviors 标准类型，函数和行为
IronPython sometimes displays different error messages for SyntaxError exceptions. The raised exception type (SyntaxError) is the same as in CPython.
IronPython有时会在遇到SyntaxError异常的时候显示不同的错误信息，但是SyntaxError类型本身是和CPython一样的。
IronPython has slightly different error messages when parsing arguments to eval(). IronPython identifies the file name as "<string>", but CPython does not report anything as a file name or that the error was found while parsing a string.
当eval()解析参数出错时IronPython会提示略有不同的错误信息。它会认为文件名是“<string>”而CPython不会报告任何关于文件名或者解析字符串的出错信息。
IronPython allows __slots__ to be defined on subclasses of tuple (for example, “class foo(tuple): __slots__ = ‘abc’”). CPython does not allow this and instead raise a TypeError stating non-empty slots are not supported on subtypes of tuple.
IronPython允许__slots__在tuple的子类中被定义（比如“class foo(tuple): __slots__ = ‘abc’”）。而CPython是不允许这样的，它会产生一个TypeError以表明空slot在tuple子类中不被支持。
IronPython cannot call __reduce__ or __reduce_ex_ on None. IronPython mistakenly believes it does not have an instance and therefore disallows calls of __reduce__ and __reduce_ex__ on None. For __reduce__ both implementations raise a TypeError but for different reasons. For __reduce_ex__ IronPython throws an exception, but CPython can successfully reduce the None object.
IronPython不能对None调用__reduce__或者__reduce_ex__。它会误认为这不是一个实例对象从而禁止调用。这两种实现都会在__reduce__中产生TypeError但是原因却不同。对于在None上调用__reduce_ex__，IronPython会产生一个异常而CPython却成功执行。
When dir is used on instances of a type that has a metaclass, the resulting list has some missing attributes. By default CPython defines __delattr__, __getattribute__, __hash__, __setattr__, and __str__. IronPython does not display these in dir()’s results but they are callable.
对有metaclass的类型的实例调用dir会丢失一些属性信息。一般CPython定义了__delattr__，__getattribute__，__hash__，__setattr__和__str__。在IronPython中这些可以调用但dir()的结果中却没有
Tracebacks display carets indicating the column for syntax errors where there are invalid assignments (for example, “def f(x): [x for x in x] = x”). CPython does not do this. Reproducing this behavior requires that you use the CPython standard library for displaying tracebacks.
对于非法的赋值语句Traceback会显示标识符来指明出错的列（比如“def f(x): [x for x in x] = x”）。这在CPython上是没有的。重现这种特性需要你使用CPython标准库来显示traceback信息。
When getting a method from a class that has not been instantiated, IronPython returns an unbound method while CPython returns a function.
class C(object):
def foo(self): pass
print C.__getattribute__(C, 'foo')
如果从一个没有实例化过的类中取得一个方法的时候，IronPython会返回一个没有绑定的方法而CPython会返回一个函数。
class C(object):
def foo(self): pass
print C.__getattribute__(C, 'foo')
IronPython allows calling __setattr__ on types. CPython disallows this and raises a type error, stating that you can’t apply __setattr__ to a type object:
class foo(object): pass
foo.__setattr__(foo, ‘__str__’, ‘bar’)
IronPython允许对type对象调用__setattr__。而CPython是不允许的。它会产生一个TypeError来指明不能在type对象上运用__setattr__。
class foo(object): pass
foo.__setattr__(foo, ‘__str__’, ‘bar’)
IronPython modules have a __dict__ attribute that contains the dictionary for the module. In IronPython “dir(__dict__)” displays the usual attributes for a dictionary, but CPython raises a NameError because __dict__ is not defined.
IronPython模块有一个__dict__属性，其中包含这个模块的dictionary。IronPython中“dir(__dict__)”显示通常dictionary的属性，而CPython会由于没有定义__dict__而产生一个NameError。
IronPython catches string exceptions by value, but CPython catches string exceptions by reference. For example, IronPython will catch this exception, but CPython won’t:
try: raise 'abc'
except 'a' + 'bc': pass
捕获字符串异常时 IronPython使用值而CPython使用引用。比如IronPython会捕获下面这个异常而CPython不会：
try: raise 'abc'
except 'a' + 'bc': pass
When accessing a file with universal new line support, IronPython and CPython can return different sizes for the file after reading partial strings.
没有使用通用换行符支持访问一个文件的时候，读取部分字符之后IronPython会返回与CPython不同的文件大小。
IronPython and CPython display different error messages when calling a user type that does not take any parameters, but they do raise the same exception type.
如果在调用一个用户类型时没有带任何参数，IronPython显示与CPython不同的错误信息但产生的异常类型是相同的。
The sys.version value is different between the two implementations.
两个实现中的sys.version有不同的值。
The maximum recursion limit in IronPython is unlimited by default, and you can call sys.setrecursionlimit() to set it to the maximum stack height.
IronPython默认是没有最大递归限制的。你可以调用sys.setrecursionlimit()来设置到最大栈高。
IronPython is more lenient regarding the use of keyword arguments in many circumstances. For example, “[].append.__call__(item=’abc’)” works in IronPython but raises an exception in CPython. Regarding _weakref, IronPython allows using keyword arguments on the weakproxy method wrappers. IronPython is also less restrictive for some string methods. For example, the following works in IronPython but raises an error in CPython:
x = ""
x.center(1, fillchar='*')
很多情况下IronPython对命名参数的使用更宽松。比如“[].append.__call__(item=’abc’)”可以在IronPython上执行但是在CPython上会产生一个异常。对于__weakref，IronPython允许在weakproxy方法封装上使用命名参数。IronPython在一些字符串方法上也更加宽松一些。比如下面的代码在IronPython上工作而CPython上会产生一个错误：
x = ""
x.center(1, fillchar='*')
IronPython has a different type hierarchy than CPython for representing system types. IronPython uses a single base class with distinct subtypes for built-in and user types. If programmers try to test whether an object is a type object by using Python's identity operator (is), instead of using instanceof(), then they may get different results.
对于表现系统类型IronPython的类型层次关系与CPython不同。IronPython使用一个单基类和不同的子类型来实现内置类型和用户类型。如果程序员使用Python的同一性操作符（is）而不用instanceof()来测试一个对象是不是一个type对象的话会得到不同的结果。
IronPython allows setting attributes on built-in functions.
IronPython允许设置内置函数的属性。
IronPython does not allow you to set attributes on __builtins__, but CPython does let you do this.
IronPython不允许你对__builtins__设置属性，而CPython恰恰相反。
IronPython allows you to set the value of __builtins__, as does CPython, but the results are different. For example, import will no longer work in IronPython, but the built-in function min() will continue to work.
IronPython允许你更改__builtins__的值，CPython也可以，但是两者的结果不同。比如，import将在IronPython上工作，而内置函数min()可以继续工作。
IronPython reports the value of __builtins__ to be a type, but CPython reports it to be a module.
IronPython认为__builtins__的值是一个类型对象，而CPython认为是一个模块。
IronPython does not include local variables in co_varnames. For example, "foo.func_code.co-varnames" for "def foo (x, y): z = 10" only returns 'x' and 'y'.
IronPython中co_varnames并不包括局部变量。比如对于"def foo (x, y): z = 10"，"foo.func_code.co-varnames"只返回’x’和’y’。
IronPython raises a ValueError for very large exponents (for example, 10 ** 735293857239475) while CPython hangs trying to compute the number.
We probably won't fix this one.
IronPython对于特别大的指数（比如10 ** 735293857239475）产生一个ValueError而CPython会因尝试计算这个数而挂起。这个问题将不会被修正。
IronPython's compile() function behaves differently than CPython's compile() function in some cases. CPython's compile function raises a SyntaxError for some trailing whitespace, but it does not do this when compiling a file. For example, the "x = compile('def f(a):/n/treturn a/n/t', '', 'single')" trailing /t causes an error in this case.
We do not intend to fix this difference.
有时IronPython的compile()函数有不同于CPython的表现。CPython的编译函数对于一些行末空格会产生一个SyntaxError，但在编译一个文件时这不会出现。比如"x = compile('def f(a):/n/treturn a/n/t', '', 'single')"末尾的/t会导致这种状况。这个问题将不会被修正。
IronPython uses unicode characters and strings, not ASCII as CPython does. For example "'%c' % i" for 255 < i <65536 raises an error in CPython but succeeds in IronPython.
We may wait to see how Python3k incorporates unicode before fixing this issue.
不像CPython使用ASCII，IronPython使用unicode字符和字符串。比如"'%c' % i"对于255 < i <65536会在CPython里产生一个错误而不会在IronPython中有问题。我们修正这个问题之前可能会等待看Python3k如何整合unicode。
IronPython will compile files whose identifiers use non-ASCII characters if the file has an encoding comment such as "# -*- coding: utf-8 -*-". CPython will not compile such a file in any case.
如果源文件中有如"# -*- coding: utf-8 -*-"这样的编码注释，IronPython编译时可以接受使用非ASCII字符的标识符，而CPython从不会编译这样的文件。
IronPython does not support a DeprecationWarning mechanism.
IronPython不支持DeprecationWarning机制
IronPython does not support a -W switch to control warnings.
IronPython不支持-W开关来控制告警。
IronPython has slightly different system-defined attribute names on some types. For example, try "dir(True)" in both CPython and IronPython.
IronPython在一些类型上使用了略有不同的系统定义属性名称。比如在CPython和IronPython上测试"dir(True)"。
Setting sys.std* attributes does not affect IronPython’s console behavior.
设置sys.std*属性不会对IronPython的控制台行为起作用。
If executing within the dynamic context of a generator, and an exception is raised, IronPython exhibits a different behavior than CPython. IronPython will continually re-raise the same exception every time you call next() on the generator. CPython raises a StopIteration exception on subsequent calls to next().
如果在生成器的动态上下文中执行时产生一个异常，IronPython会有出与CPython中不同的表现。当你每一次在生成器上调用next()时IronPython会继续再抛出相同的异常。CPython会在接下来的next()调用中产生一个StopIteration异常。
IronPython does not handle falling off the end of generator functions the same way as CPython. When you call next() after a last yield statement has executed, IronPython continually returns execution to the point immediately after that yield statement, executes to the end of the function, and then raises a StopIteration exception. CPython executes from the last yield to the end of the function only one time, and then subsequent calls to next() immediately raise a StopIteration exception.
IronPython处理生成器函数结束的方法与CPython也不相同。当你在最后一个yield命令执行之后调用next()时，IronPython会马上返回执行yield后面的指令继续执行直到函数结束，然后产生一个StopIteration异常。CPython只允许执行yield后面的代码一次，之后对next()的调用会马上产生StopIteration异常。
IronPython does not allow yield statements in nested try blocks.
IronPython不允许yield命令嵌入在try指令块中。
IronPython raises an exception when it cannot convert a string to a unicode string, and CPython just returns the argument to unicode().
当IronPython不能把一个字符串转换成一个unicode字符串时会抛出一个异常，而CPython只是返回执行unicode()的结果。
IronPython's _codecs module implementation is incomplete. There are several replace_error/lookup_error handlers that IronPython does not implement.
IronPython的_codecs模块实现不完整。有些replace_error/lookup_error handler没有实现。
IronPython does not implement type.mro, and user overrides do not affect how a type's __mro__ works. In CPython you can override a type’s mro method to alter the method resolution order, but IronPython raises an exception if you try to set type.mro. Calling mro on any type raises an exception, but __mro__ still works on types.
IronPython没有实现type.mro而且用户的重载不会对类型的__mro__如何工作有影响。CPython里你可以重载一个类型的mro方法来改变方法的解析顺序，但是如果你试图设置type.mro会得到一个异常。在任意类型上调用mro都会抛出一个异常，但是__mro__在类型上依然工作。
IronPython does not support overriding __getattribute__ for some user-defined subclasses of built-in types.
IronPython不支持重载一些内置类型的用户自定义子类的__getattribute__。
When printing expression results in the console, IronPython calls __str__ on new style classes while CPython calls __repr__.
当打印表达式在控制台里执行时，IronPython在新型类上使用__str__而CPython使用__repr__。
IronPython gives different error messages and raises different exceptions in some situations using the complex built-in function. For example, calling complex on an old style class instance in CPython raises an AttributeError due to no __float__ function existing, but IronPython raises a TypeError. Doing the same thing on a new style class raises a TypeError in both implementations, but CPython's message explains the argument must be a string or number while IronPython's message just says it cannot convert to complex.
使用内置函数complex时IronPython有不同的出错信息和不同的异常。比如对旧式类实例调用complex，CPython会由于没有__float__函数而产生一个AttributeError，但IronPython产生一个TypeError。对新式对象进行同样调用，两者都会产生TypeError，但CPython的出错信息是参数必须是字符串或者数字而IronPython的是不能转换成complex。
IronPython raises different exceptions than CPython (and sometimes raises exceptions when CPython does not) in isinstance() with complex class definitions that affect bases and return bases in various ways. See
CodePlex
bug 2169 for details.
如果复杂类型在定义中影响到基类而且通过多种方式返回基类，在对这种对象调用isinstance()时，IronPython产生不同的异常（有时甚至是CPython没有的异常）。详情请参考
CodePlex
bug 2169
。
IronPython’s behavior differs from CPython’s behavior if you call del on __builtin__.pow and then try to print the value of pow within a module. Importing or executing the module from the command line in IronPython will print "<built-in function pow>" while CPython raises a NameError.
在你调用对__builtin__.pow调用del，而后试图在一个模块里打印pow的值时，IronPython表现不同。在IronPython中从命令行引入或者执行模块会打印"<built-in function pow>"，而CPython产生一个NameError。
IronPython has extra attributes ('msg' and 'clsException') on exception objects.
IronPython在异常对象中有额外的属性('msg' and 'clsException')。
IronPython does not return a code object if it encounters a syntax warning when calling compile(). IronPython raises a SyntaxWarning exception, but CPython catches and prints the exeption before returning a code object.
在调用compile()时如果IronPython遇到语法告警则不返回code对象。IronPython产生一个SyntaxWarning异常，而CPython在返回code对象之前捕获并打印这个异常。
IronPython does not invoke the __setattr_ attributes for old style classes when setting an attribute. See
CodePlex
bug 2295 for more info.
IronPython supports fromkeys() on some dictionaries for which CPython does not provide fromkeys() support. For example, “file.__dict__.fromkeys” returns a method in IronPython and raises a TypeError in CPython.
IronPython对某些字典对象支持fromkeys()而CPython没有。比如“file.__dict__.fromkeys”在IronPython中返回一个方法对象而CPython产生一个TypeError。
IronPython allows you to set a key of value 2 in class’s __dict__, but CPython does not. CPython only allows you to do this with the __dict__ of a class instance, not the class itself. Try “C.__dict__[2] = ‘2’”.
IronPython允许你设置设置类中的__dict__的键为2的值，但是CPython不可以。CPython只允许通过类实例的__dict__来实现这种操作。可以试验“C.__dict__[2] = ‘2’”。
IronPython supports __slots__ for subtypes of type, but CPython does not. For example, the following works in IronPython:
class foo(type):
__slots__ = [“abc”]
IronPython支持type的子类型的__slots__但是CPython不支持。比如下面的代码可以在IronPython上工作：
class foo(type):
__slots__ = [“abc”]
IronPython doesn’t support supplying named values for format string directives if the name has parentheses in it, for example, “%((foo))s” % {‘(foo)’ : ‘fooval’ }.
IronPython在字符串格式化指令中不支持包含括号的命名值，比如“%((foo))s” % {‘(foo)’ : ‘fooval’ }。
When formatting float numbers, IronPython doesn’t raise an Overflow exception for formatting with too high a precision (for example, >=67).
格式化一个浮点数的时候IronPython不会因为格式要求过高的精度（比如大于67位）而产生Overflow异常。
IronPython doesn’t support overriding __getattribute__ on built-in objects.
IronPython不支持重载内置对象的__getattribute__。
IronPython cannot create weakref proxies that reference deque and set objects.
IronPython不能创建对deque和set对象的weakref代理。
IronPython supports ‘continue’ statements in ‘finally’ clauses.
IronPython在finally’语句中支持continue。
IronPython’s built-in function reversed() behaves slightly differently than CPython’s reversed() function. For example, calling len() on the result of “reversed(xrange(5))” raises a TypeError. Also, calling len() on the result of calling reversed() on custom iterators (for example, a class that supports __getitem__ and __len__) fails. This behavior happens because the reversed() iterator doesn’t provide access to the original __len__ implementation.
IronPython的内置函数reversed()的表现与CPython略有不同。比如，对“reversed(xrange(5))”的结果调用len()会产生一个TypeError。同样，reversed()在定制迭代器（比如支持__getitem__和__len__的类）上的执行结果如果使用len()也会失败。这是因为reversed()迭代器没有提供对原始__len__实现的访问。
IronPython’s implementation of buffer doesn’t support binary operations between buffers and strings (for example, concatenation with a buffer and string).
IronPython的缓存实现不支持在缓存和字符串之间使用二元操作符（比如联接一个缓存和一个字符串）
IronPython does not call __len__ on old style classes when slicing. This results in the end index potentially being negative in IronPython. CPython adjusts to the appropriate end index, but it raises an AttributeError if the old style class does not have a __len__ attribute.
IronPython在slicing时不会对旧式对象调用__len__。这最终可能会导致在IronPython中末尾位置是负数。CPython矫正成了适当的值但是如果旧式对象中没有__len__属性会产生一个AttributeError。
IronPython does not allow opening partitions and drives for read as binary files, but CPython does allow this. For example, IronPython detects the “//./” idiom in “f = file(r'//./PhysicalDrive', 'rb')” and raises a ValueError since .NET does not support this functionality.
IronPython不允许像读取二进制文件那样打开分区和驱动器，但是CPython可以。比如IronPython会检查出“f = file(r'//./PhysicalDrive', 'rb')”中的“//./”，并产生一个ValueError。这是因为.NET不支持这样的功能。
IronPython’s built-in apply function has a bug in that it requires at least two arguments.
IronPython的内置apply函数有一个bug，它需要至少两个参数。
Printing numbers on a machine with French locales produces different output:
在使用法语区域设置的机器上打印数字会有不同的结果：
|
IronPython
|
CPython
|
|
>>> x = 1.234
>>> x
1.234
>>> print x
1,234
|
>>> x = 1.234
>>> x
1.234
>>> print x
1.234
|
Small integer caching in IronPython is different than in standard CPython. If you set i = 2 and then test "i is 2", the code produces different results in IronPython and CPython. However, the consistency of the result of such expressions is not guaranteed even within CPython, which seems to be using different small integer caching strategies for different situations:
小整型缓存方面IronPython与标准CPython不同。如果你设i=2然后测试"i is 2"将会得到不同的结果。但是这种表达式的结果的一致性连CPython也没有保证。CPython好像针对不同的情况使用了不同的小整数缓存策略:
|
IronPython
|
CPython
|
|
>>> i=5
>>> i is 5
False
>>> i=5000
>>> i is 5000
False
|
>>> i = 5
>>> i is 5
True
>>> i = 5000
>>> i is 5000
False
|
3 Regular Expressions 正则表达式
IronPython returns a regular expression match when your pattern matches the beginning of a string, but you supplied a start index past the start of the string. In this same case CPython returns None.
当你的模式匹配到字符串起点，但你提供了一个这个起点之后的起始位置时IronPython返回一个正则表达式匹配。这种情况下CPython返回None。
IronPython raises a more specific exception (IndexError instead of sre_constants.error) when using an invalid group reference in regular expressions with named groups -- for example, “re.sub(r'(?P<id>b)', '/g<1>/g<30>blah', 'bb')”.
当在包含命名组的正则表达式中使用非法组引用时IronPython产生一个更详细的异常（IndexError而非sre_constants.error）。
Since the IronPython regular expression implementation uses the .NET Framework regular expressions implementation, IronPython supports some syntax not supported by CPython (note, CPython has a similar syntax for affecting the entire pattern, but it is different than these mechanisms in syntax and scope of effect):
由于IronPython的正则表达式实现使用了.NET Framework的相应部分，它支持一些CPython不支持的语法（注意：CPython对于整个模式有一个类似的语法，但是这在语法和应用范围上有所区别）：
·
(?i:foo) -- ignore case
忽略大小写
·
(?m:foo) -- multi-line mode (^ and $ match at the beginning and end, respectively, of any line, not just beginning and end of the whole string)
多行模式（^和$分别匹配任意行的而非整个字符串的开始和结尾）
·
(?s:foo) -- single line mode (period “.” matches every character instead of every character except /n)
单行模式（点号匹配除/n以外的所有字符）
·
(?x:foo bar) -- ignore whitespace in the pattern
忽略模式中的空白
4 Extension Modules 扩展模块
IronPython support importing .NET Frameworks assemblies as extension modules. Usually you need to import the built-in extension module clr and then call one of the clr.AddReference... functions.
IronPython支持引入.NET Frameworks程序集作为扩展模块。通常你需要import内置模块clr，然后调用clr.AddReference...函数中的一个。
Some CPython built-in extension modules do not exist in IronPython:
一些CPython内置模块不在IronPython之中:
|
_bisect
_codecs_hk
audioop
_multibytecodec
parser
array
msvcrt
_codecs_kr
|
_heapq
_codecs_jp
imageop
mmap
_subprocess
_codecs_tw
regex
|
zipimport
xxsubtype
_codecs_cn
md5
_codecs_iso2022
rgbimg
_csv
|
signal
_hotshot
sha
cmath
_symtable
_winreg
strop
|
The sys module does exist though it is not listed in sys.builtin_module_names.
尽管sys模块不出现在sys.builtin_module_names中，但它确实存在。
IronPython has these additional modules: 're', 'copy_reg', 'socket'. These are built in rather than being implemented in Python either to leverage the .NET Frameworks or to avoid dependencies on CPython for a minimal installation.
IronPython有些额外的模块，包括're', 'copy_reg', 'socket'。它们都是内置的而非用Python类实现，为了影响.NET Frameworks或者去除最小安装时的对CPython依赖。
Passing malformed data to binascii.a2b_base64 results in different error messages. IronPython will raise a TypeError in this situation, and CPython will raise a binascii.Error. For example try executing “binascii.a2b_base64(‘A’)”.
传送畸形数据到binascii.a2b_base64会导致不同出错信息。这种情况下，IronPython会产生一个TypeError而CPython会产生一个binascii.Error。比如尝试执行“binascii.a2b_base64(‘A’)”。
IronPython’s pickle module doesn’t support fast mode.
IronPython的pickle模块不支持快速模式。
The pickle implementation in IronPython doesn’t handle all cases of pickling deque objects (recursive deque for example) and sets.
IronPython中的pickle没有实现处理保存deque对象和set对象时的所有情况（比如递归的deque）。
The doctest module does not run in IronPython.
doctest模块不能在IronPython上运行。
IronPython doesn’t support the select module.
IronPython不支持select模块。
IronPython doesn’t support the _testcapi module.
IronPython不支持__testcapi模块。
IronPython doesn’t implement socket.getservbyname() because IronPython uses .NET base class libraries to implement the socket module, and they don’t provide the support for that function.
IronPython没有实现socket.getservbyname()。这是因为IronPython使用没有提供这种功能的.NET基础类库来实现socket模块。
IronPython doesn’t support the makefile method on socket objects.
IronPython不支持socket对象上调用makefile方法。
IronPython does not have an xxsubtypes built-in module.
IronPython没有xxsubtypes内置模块。
IronPython has no os.system function.
IronPython没有os.system函数。
5 Interpreter and Environment 解释器与运行环境
IronPython does not by default have the standard CPython libs on its path (for example, . You can fix this by adding these two lines to the site.py file in the IronPython lib directory:
import sys
sys.path.append(r"c:/python24/lib")
默认情况下IronPython在它的路径下没有标准CPython的库。你可以通过在IronPython的lib目录下的site.py中增加两行来修正这个问题：
import sys
sys.path.append(r"c:/python24/lib")
IronPython does not redirect the interpreter's error output in response to setting sys.stderr.
IronPython不会因设置sys.stderr而重定向解释器错误。
IronPython has different command line editing support than CPython.
IronPython的命令行编辑支持与CPython不同。
IronPython supports different command line options than CPython supports. Invoke ipy.exe with the "-?" switch to see options.
IronPython支持与CPython不同的命令行选项。使用“-?”开关调用ipy.exe可以看到这些选项。
IronPython's sys.builtin_module_names tuple contains different values than CPython's result. See section
Extension Modules for differences.
IronPython has several incompatibilities relating to the interpreter and the sys module’s hooks:
IronPython在解释器和sys模块上存在不兼容问题：
·
settrace
Calling this raises a NotImplementedException.
调用这个会产生NotImplementedException
·
api_version
This always has the value: "IronPython does not support the C APIs, the api_version is not supported".
这个值总是"IronPython does not support the C APIs, the api_version is not supported"。
·
displayhook
Setting this will throw a NotImplementedException.
设置这个会抛出NotImplementedException。
·
_getframe
Calling this function raises a ValueError exception.
调用这个函数会产生ValueError异常。
·
__excepthook__
IronPython does not support __excepthook because it does not implement sys.excepthook(). IronPython does not currently support replacing function definitions in the sys module. Note, excepthook is an attribute in the sys module, but it is bound to a string: "IronPython does not support sys.excepthook".
IronPython不支持__excepthook因为它没有实现sys.excepthook()。IronPython现在不支持替换sys模块中函数的定义。注意，excepthook是sys模块中的一个属性，但它被绑定到了一个字符串"IronPython does not support sys.excepthook"。
·
setcheckinterval
IronPython does not use the value set with this function.
IronPython 不使用这个函数设置的值。
IronPython allows access to __dict__, __module__, __class__, and __init__ at the global level, but CPython does not.
IronPython 在全局层面允许访问__dict__，__module__，__class__和__init__，而CPython是不可以的。
Python prohibits using identifiers before the occurrence of global statement if the global statement includes the identifier. In these cases, CPython reports a syntax warning while IronPython raises a SyntaxWarning exception. For example:
def f():
a = 1
global a
如果一个标识符在一个全局指令中使用，Python不许在出现这个全局指令之前使用标识符。这种情况下，CPython报告一个语法警告而IronPython产生一个SyntaxWarning异常。比如：
def f():
a = 1
global a
The sys._getframe() function is not supported by IronPython. In addition, the semantic of deleting the sys._getframe is different than CPython’s. In IronPython, once sys._getframe is deleted, it is not possible to store a value to sys._getframe.
IronPython不支持sys._getframe()。而且删除sys._getframe的语义也与CPython不同。IronPython中一旦sys._getframe被删除，想再向sys._getframe保持值是不可能的。
6 Garbage Collection 内存回收
IronPython has a more modern GC whereas CPython uses reference counting, and IronPython's GC choice is considered to be a valid and acceptable implementation. This has several effects which are listed below.
IronPython有更新型的GC而CPython仍使用引用计数。IronPython的GC选择被认为是有效而令人满意的实现。这方面的一些影响将列举如下。
IronPython users don't need to worry about handling circular references as these are guaranteed to be collected properly. This behavior is acceptable.
IronPython用户步需要担心循环引用，它们将被正确的回收。这种表现令人满意。
IronPython does not have guarantees for when finalization or system resource freeing occurs. This can cause problems for people who use open("foo", 'r').read() excessively. This behavior is acceptable.
IronPython不保证终结化或者系统资源回收何时出现。这对于过度使open("foo", 'r').read()的人会是一个问题。这种表现可以接受。
IronPython does not immediately invoke __del__ methods when del is called on a variable; it happens during the next GC pass. Similarly, using del on an object that a weakref object refers to and then immediately testing if the weakref is None may return False. This behavior is acceptable.
IronPython在del调用时不会马上而是在下一GC过程中调用__del__方法。同样，del一个被weakref的对象之后马上测试weakref是不是None的结果会是False。这种表现可以接受。
Calling sys.getrefcount raises a NotImplementedError. Alternatively IronPython could always return some positive constant since there's a reference that was passed to getrefcount.
调用sys.getrefcount会产生一个NotImplementedError。IronPython打算在参数是引用时返回一些正整数来替换现在的方式。
In CPython you can observe the re-use of some tuple objects in some situations, but this is an implementation detail that no one should depend on. In IronPython there is no such re-use.
一些情况下在CPython里你可以观察某些tuple对象的重用，但是这是一个没有人依赖的实现细节。IronPython里没有这些。
扫一扫
312
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
