[IronPython] IP & Python for .NET 2.0 roadmap

Brian Lloyd brian at zope.com
Tue Jul 26 05:40:27 CEST 2005

Hi all - sorry to cross-post to the IP list, but I know there 
are some folks who follow both projects and might want a head's
up -- please post any replies to the pythondotnet list unless it 
really is pertinent to IP per se.

I'm about to wrap up development on Python for .NET and make a 
1.0 release, and wanted to post a roadmap for 2.0. The next (and 
hopefully last) RC release of 1.0 will include a few changes to 
make out/ref param behavior compatible with IronPython, followed 
by a final 1.0 release.

The Roadmap: Python for .NET 1.x will be targeted to the .NET 
1.x runtime. It will not be terribly compatible with any code 
developed for IronPython.

Python for .NET 2.x will be targeted to the .NET 2.x runtime, 
and Python code for it will be as compatible as possible with 
the IronPython runtime. Meaning, I hope that Python code that 
runs on pythonnet 2.x will run without changes on IronPython.

Generally, I think all of us are excited to see the sustained 
effort being applied to IronPython. Having a code-compatible 
'CLR consumer' implementation based on CPython should be helpful 
not only in providing an upgrade path for the future for users 
of pythonnet but also provide some interesting possibilities for 
comparative conformance and performance testing, test sharing, etc.

Proposed changes for 2.0 (mostly related to IP compatibility):

  - Support for 'son of sys.LoadAssemblyByName'

    As noted on the IP mailing list, Jim doesn't like the current
    sys.LoadAssemblyByName solution

    I mostly tend to agree - at any rate, I'd like for pythonnet to 
    support whatever the successor is. (Some suggestions maybe in 
    another thread)

  - API compatibility with the IP PythonEngine

    I'd like the pythonnet PythonEngine to support the API of the IP 
    engine, to make it at least possible to swap back and forth with 
    a minimum of effort. The current pythonnet PythonEngine API would 
    be deprecated (but available) until 3.0. 

    A probable breaking change here is that pythonnet requires managed 
    code to be aware of the GIL -- IP seems to have gotten rid of that 
    requirement (hooray!).

    The gist is that it would be nice if embedders writing in C#, VB or 
    other less-dynamic managed code could swap back and forth with no 
    more than some namespace futzing if possible.

  - Support syntax for resolution of generic types, methods and
    overload resolution

    IP has (or soon will have) introduced some spelling to support 
    instantiation of generic types and fine resolution of overloaded 
    methods. It should be no problem to support the spellings that 
    have so far been proposed:

    # instantiate a generic type
    from System.Collections.Generic import List
    x = List[str]()

    # realized generic type as first class object
    c = List[str]

    # open generic types as objects -- not sure yet how this would 
    # or wouldn't relate to IP plans
    o = List
    <open type 'List' ...>

    # pinpoint overloads -- note that we would allow the use of 
    # python types to indicate CLR types in these limited cases 
    # a la IP (str == System.String, int == System.Int32, etc.)

  - Leverage LCG in the runtime

    There are a few places that could benefit from LCG -- this is 
    a 'nice to have', since we'll already benefit from some of the 
    CLR 2.x improvements to caching of reflected members, etc.

  - Import spelling

    This is probably the most controversial and potentially breaking 
    change for users of Python for .NET 1.x. 

    PythonNet currently uses a top level 'CLR' module to contain all 
    modules (namespaces) imported from the CLR. For 2.x, I would 
    propose killing this in favor of the the direct spelling used by 
    IP (import System.Console vs. import CLR.System.Console).

    This will have some effect on performance, but I think it will be \
    manageable. If at all possible, I'd like to arrange for the CLR.xxx 
    spelling to remain supported (but deprecated) until 3.0, unless it 
    would really kill perf.

Note that all of these changes are focused on the 'CLR consumer' 
aspect of Python. I don't know of any public designs for IP as a 
CLR producer (and having CPython act as a producer introduces a 
whole new world of problems), so at this point I'm only looking at 
compatibility from a consumer perspective.


Brian Lloyd        brian at zope.com
V.P. Engineering   540.361.1716              
Zope Corporation   http://www.zope.com 

More information about the Ironpython-users mailing list