[IronPython] IronPython 3

[Dino Viehland]

Michael wrote:
> I'd love to see IronPython 3 as a separate DLR language that could be
> used alongside IronPython 2.X. That way an IronPython 2 engine could use
> IronPython 3 engines and vice versa. This would allow Python 3 apps to
> use Python 2 libraries (with a wrapper layer) and vice-versa, and be
> unique in the Python world (well the Jython guys could do it as well).

Do you actually want to have both engines running in the same ScriptRuntime?
If so what would be the file extension for IronPython 3?  .py3?  The reason
I ask is currently ScriptRuntime's have a list of all languages and what
extensions they support.  That enables things like runtime.ExecuteFile to
work and we don't allow duplication of extensions.

> I guess there are two ways of doing it. Either provide a single
> implementation where Python engines can be created as 2.X engines or 3.X
> engines. I imagine this would be fairly painful to do. Alternatively
> provide a separate set of assemblies for Python 3 - IronPython3.dll,
> IronPython3.Modules.dll etc. so that projects can reference *both* as
> separate dlr languages - I imagine this might make sharing code between
> the implementations a bit 'fiddly'.

Actually we could possibly even get away w/ not renaming them, just updating
their version numbers.  If both 2.6 and 3.1 were in the GAC you could just 
refer to them by their fully qualified name and projects could reference both
of them.  Even if they're not in the GAC they could be in a private path
below the app base such as "IronPython2" and "IronPython3" although that
may be more of a pain.

The big thing here would be ensuring that the version of Microsoft.Scripting.dll 
between them is shared so that you can use one set of hosting APIs to host them both.  
That's certainly theoretically possible even if we do need to put out a 2.6.? 
w/ a new Microsoft.Scripting.dll to align them.

I agree supporting both 2.x and 3.x in the same DLL would be a little bit
annoying.  In particular I'm thinking old classes will be the biggest pain. 
But I think this is the approach we will *start* with as we start migrating 
to 3.x.