Python on .NET (Jim Hugunin).notes

Wednesday, March 23, 2005

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)