Dino Viehland wrote:
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.
Not particularly. '.py' is the correct extension for both Python and
Python 3. I was anticipating having them as separate languages and
therefore need distinct ScriptRuntimes.
But just as you can use IronRuby objects from IronPython I would expect
to be able to use Python 3 objects from Python 2. The downside is that a
Python 3 dictionary wouldn't be an instance of the Python 2 dict (so
isinstance would fail) which is why I anticipated having to use a
wrapper layer.
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.
Can one process load different versions of the same assembly? I thought
that wasn't possible.
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.
I can see that this is already partly in place but I can easily imagine
it being a real pain long term.
I mainly just wanted to get my use case out there early so it could be
taken into account.
All the best,
Michael
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
