Professional IronPython

IronPython Differences 
with CPython
WHAT’S IN THIS APPENDIX?
➤
Considering standard types, functions, and behaviors
➤
Defining which CPython libraries are missing
➤
➤
Defining which extension modules are changed or missing
➤
➤
Working with custom CPython extensions
➤
➤
Using the interpreter and environment
➤
➤
Using garbage collection
➤
➤
IronPython has a lot of functionality, but throughout the book you’ve probably noticed 
that it isn’t precisely like CPython. In fact, there are more than a few differences between 
IronPython and CPython. Some of these differences occur because of the way IronPython is 
written. (IronPython is a managed application, CPython is written in C.) However, some of 
the differences result from Microsoft’s interpretation of the specification or its decision not to 
follow the specification in order to make IronPython interact with the other .NET languages 
with greater ease. Whatever the differences, you need to know about them in order to avoid 
potential problems when working through your applications.
ImPlEmENTINg STANDArD TyPES, 
FuNcTIoNS, AND BEHAvIorS
Whenever you have two different teams working on a software product, some differences will 
occur in implementation and behavior. The IronPython team is currently working on these 
differences, but you can probably expect some of them to remain long-term. For example, you 
A
548592bapp01.indd 421
2/24/10 12:49:56 PM
www.finebook.ir

---

422
❘
APPENDIX A
IronPython DIfferences wIth cPython
might see different error messages when working in IronPython than when you work with CPython. 
The error number is the same, but the message is different. Other than making it harder to search 
for information about the error online, the difference in wording really doesn’t cause a show-stopper 
problem. Both IronPython and CPython carry on as before. However, the differences can prove con-
fusing to developers who are used to looking at the error message rather than the error number, so 
it’s important that both products begin to display the same error messages.
It would be easy to beat up on one party or another when it comes to language 
implementations. The problem is that the Python language specification found 
at 
http://www.python.org/doc/current/reference/
 isn’t always as clear 
as it could be about certain language characteristics. The lack of clarity has 
translated into different implementations of some features. Of course, now that 
these problems are clear, the specification should get an update to clarify them. 
Unfortunately, past experience shows that no matter how well the specification is 
written, there will always be some wiggle room for different implementations so 
you need to learn to work around them when building your application.
You’ll find other cases where IronPython and CPython behave differently. For example, when dis-
playing a traceback after an error, IronPython provides a caret (^) to show the origin of the error. 
CPython doesn’t provide the functionality.
There are a few cases where IronPython and CPython react differently to code. The following list 
contains the most common issues that you’ll encounter. (Because the IronPython developers are con-
stantly fixing issues and developers are finding new ones, you’ll also want to review the issue list at 
http://ironpython.codeplex.com/WorkItem/List.aspx
.)
➤➤
IronPython doesn’t support use of 
__reduce__()
or 
__reduce_ex__()
on the 
None
object. 
The problem is that IronPython doesn’t think it has an instance in which to use either method.
➤
➤
IronPython supports the use of 
_slots_
on a 
tuple
, whereas CPython raises an error if you 
try to use 
_slots_
. For example, the following code runs fine in IronPython.
class foo(tuple):
_slots_ = ‘abc’
➤
➤
Sometimes IronPython fails to show all the members of a type that has a metaclass. The 
most common missed members are 
__delattr__()
, 
__getattribute__()
, 
__hash__()
, 
__setattr__()
, and 
__str__()
. You can still call the members.
➤
➤
If you attempt to get a method from a class that hasn’t been instantiated in IronPython, you 
get an unbound method, while CPython returns a function.
➤
➤
Some IronPython modules have a 
__dict__()
attribute defined that displays a list of the 
module content. CPython modules don’t have this feature.
➤
➤
The 
sys.version
value is different between IronPython and CPython.
548592bapp01.indd 422
2/24/10 12:49:57 PM
www.finebook.ir

---