Python on .NET (Jim Hugunin).notes
Wednesday, March 23, 2005
Implementation Running on .NET of the Python
What is .NET?
Virtual machine for multiple languages
Large number of languages in production use today
CLI not good for dynamic languages?
Jim decided to prove this, but discovered the opposite was the case
IronPython 0.2 at PyCon 2004
IronPython 0.6 at OSCON 2004 - public release under CPL
Jim gets sucked into Redmond. ;)
Announcing IronPython 0.7
BSD-style license (MS Shared Source Initiative)
Still early alpha preview
release every 2 weeks until 1.0
1.5 people committed to this by Microsoft (50% of Jim)
Jim also spends his time convincing MS that Python is Good
Designed for .NET 2.0
Influence the framework as it's being finalized
.NET 2.0 not publically released as of today
What is IronPython?
A fast Python implementation for the CLI
Integrated with the other languages of the CLI
Still an early prototype
Bringing the power of .NET to Python
Seamless access to .Net libraries from Python
Built on the .NET VM
Leverage hundreds of man-years of VM development
A way to use Python without telling your boss!
Integration with other CLI languages (C++, Java, C#, Eiffel, COBOL(!))
[Demo 1: accessing .NET libraries from Python with yet another Microsoft animated fluffy thing. Includes gratuitous dead-parrot reference.]
People are impressed by interactive scripting of Python's REPL.
It's a good selling point for Python with .NET.
Avalon is new GUI toolkit coming out of Microsoft.
XAML - XML decoupling GUI layout from impl.
Demo shows loading a calculator XAML file into the GUI
Then interactively adds a click handler across the XAML tree
Excellent Virtual Machine
Simpler Python implementation since the VM is written by someone else
Other people are doing hard work making Python faster
.NET framework averaging 70% faster than cpython
Why is Iron Python Faster?
Same architecture as CPython
Only difference is the bytecodes (IL for CLR)
Compilation can be static or dynamic
Example: Recursive factorial function in Python
Varying degrees of similarity between CPython and IL bytecodes.
Some Python ops (Truth/Falsity) require a little help (via function calls instead of single bytecodes) to map to IL
Then the bytecode gets compiled to X86 (or whatever) machine code
For operations that map directly to assembly, you get a phenomenal speedup
Everything else boils down to C or C# code
IL bytecode takes up more disk space than .pyc bytecode
Machine code takes up more memory than Python bytecode
Does this mean more cache misses? Possibly
How to get good performance?
Experiment and measure a ton - 100's of small decisions
i.e. the MS folks have tuned the CLR so that Jim is starting out with a faster platform
However, yes, IronPython does create more memory pressure than CPython does.
[Demo 2: Extending Python with C# code]
Compiled a single static method written in C#
Loaded the compiled "assembly" .dll into IronPython as a module
C#->IronPython call on 1st try!
[Demo 3: Multi-language debugger]
Demonstrates walking up the call stack
First through the C# implementation of IronPython
Then through the Python code itself that caused the exception
Demonstrates looking at the disassembly of the Python and C# code
Same debugging mechanisms for all CLR languages
The power of Python to .NET
( compatibility - not yet (IronPython 0.7)
Simple bugs (e.g. bools aren't ints yet)
Design decisions need to be revisited
Unimplemented features (2.4 stuff)
Planning on running CPython regression tests (at least as well as Jython)
Incompatibilites are bugs (at least for now)
Other kinds of differences
A few things will never match
e.g. IronPython will never have reference-counting
Some differences that are worthy of discussion
e.g. locale issues (float -> string via str, repr)
Some possible improvements that IronPython can suggest for CPython
Compatibility with Python vs. compatibility with other CLI languages
Can all strings be unicode?
What is the right locking policy? (No GIL, for example)
Can we experiment with optional static types
CLR-style methods on both Python types and on existing CLR types
Python and .NET: "Two great tastes that go great together"
.NET is good for Python
Python is a good for .NET
Q: What about Mono and Rotor?
A: Yes for sure on Rotor. Mono? Not sure, but probably.
Not fair to compare MS's speed with Mono since the latter is less mature.
Q: Memory and startup overhead of IronPython?
A: Noticeable delay on startup, not huge.
Not clear on memory yet; no measurements done so far.
Code compiled to assemblies can have reduced startup and memory costs.
Q: Any Microsoft patent encumberances on IronPython?
A: The license with IronPython talks about patents, has a FAQ
Patents that apply to IronPython itself are covered by the license.
Q: Any such patents may apply to CPython as well... Thoughts?
A: Send email to above address.
Q: Can we rely on __del__ methods being called?
A: No, can't rely on it at any particular time, but that's a bug in 0.7.
This is the same as Jython; it's an accepted change in the semantics.
Q: Will MS spend any marketing $$$ on IP or dynamic languages in general?
A: I think MS should join the PSF.
Q: Substantial differences between IronPython and Jython?
A: Great features of .NET
Delegates (strongly-typed function pointers, very efficient)
Properties (just like in Python) are very useful, as opposed to trying to map features onto naming conventions
Built-in tools for generating bytecode
Generics (parameterized types) e.g. 'A tuple of ints'
Do the multiple-language thing well (e.g. the debugger)