[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
(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 at zope.com
V.P. Engineering 540.361.1716
Zope Corporation http://www.zope.com
More information about the Ironpython-users
mailing list