[IronPython] IronPython 3

[Michael Foord]

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
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog