Implementation Running on .NET of the Python Jim Hugunin Contributors Abhay Saxena Linden Wright Andy Wright Andy Gross What is .NET? Virtual machine for multiple languages Large number of languages in production use today International Standard IronPython History 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 Demo Avalon is new GUI toolkit coming out of Microsoft. Understands XAML 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 Yay, Python ( 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 Conclusions Python and .NET: "Two great tastes that go great together" .NET is good for Python Python is a good for .NET http://workspaces.gotdotnet.com/ironpython ironpy@microsoft.com 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)