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 (http://lists.ironpython.com/pipermail/users-ironpython.com/2005-July/000805 .html) 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.) Console.WriteLine[str]("Hi") Console.WriteLine[int](6) - 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. generic-'ly, Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com