[Ironpython-users] pyc port to IKVM.Reflection

[Dino Viehland]

The use case for __clrtype__ is that sometimes a .NET class expects a real type - 
either because there need to be attributes placed on it, or it needs a normal 
constructor which doesn't take a PythonType object, or for some other oddity of 
.NET...  At the same time __clrtype__ is exposing the fact that there's a .NET type 
that's associated with each Python type and it lets you really customize it in 
anyway that you can dream about via your metaclass.  I think one of the main
scenarios in mind was frameworks like WCF but that didn't seem to go too
far (Jimmy apparently beat me to the punch and mentions some other ones).

The @clr.accepts/@clr.returns way was how we did this in IronPython 1.0/1.1 - I 
think these got used for both the static compilation feature (which was implemented
in NewTypeMaker.cs and was there to support ASP.NET) as well as our round
tripping via the WinForms designer.  But the annotations are much nicer, I would
almost think we could get away w/ supporting them before 3.x.

Another way to approach this (and maybe this is what you're already thinking from an
implementation stand point, maybe not) would be just making an easy way to define 
the façade for Python modules/classes.  That is everything gets compiled normally 
but we generate some wrapper classes automatically.  The wrapper classes could 
use the hosting APIs to import the various modules and expose them as .NET
classes.  You could even imagine that the wrapper classes are generated from
some non-turing complete language, but we could also have a script which would
generate them from a .py file automatically and allow you to tweak them.  Finally
throw in some ILMerge tools and we have a pretty decent Python->.NET DLL/EXE 
story.



> -----Original Message-----
> From: ironpython-users-bounces+dinov=microsoft.com at python.org
> [mailto:ironpython-users-bounces+dinov=microsoft.com at python.org] On
> Behalf Of Jeff Hardy
> Sent: Friday, July 06, 2012 8:24 AM
> To: Slide
> Cc: ironpython-users at python.org
> Subject: Re: [Ironpython-users] pyc port to IKVM.Reflection
> 
> Apparently I should think out loud on the issue tracker more often :) I haven't
> looked, but I'm glad to hear it was easy. I'm going to think out loud for a bit,
> but I promise it's related :).
> 
> One limitation with pyc.py is that it doesn't generate assemblies that can be
> consumed from other .NET languages directly. Using __clrtype__ IronPython
> can generate assemblies at runtime that can be consumed, but not ahead of
> time (to be honest, I don't really understand the use case for that - Dino?).
> However, using __clrtype__ requires clrtype.py, which is floating around
> unsupported somewhere.
> 
> Ultimately, I'd like to unify the two static compilers (runtime and AOT),
> keeping the __clrtype__ mechanism, but also letting pyc.py create
> consumable assemblies.
> 
> My initial thought was to port both clrtype.py and pyc.py code-generation
> parts to C# (say IronPython.Compiler), put the clrtype helpers in the clr
> module, and have pyc.py just be a frontend to that assembly to handle
> command-line options and such.
> 
> The tricky part is recognizing when to generate a CLR class from just the
> static code. A thought I had (which is a bit hackish) was to have the static
> compiler recognize a few special names and switch to generating a CLS-
> compliant class:
> 
>     import clr
> 
>     class Foo(clr.object): # or clr.struct, or clr.interface
>         @clr.accepts(int)
>         @clr.returns(str)
>         def bar(self, x):
>             pass
> 
> In Python 3, it become a bit cleaner:
> 
>     import clr
> 
>     class Foo(clr.object): # or clr.struct, or clr.interface
>         def bar(self, x : int) -> str:
>             pass
> 
> I still haven't thought about generics, or subclassing .NET classes, or
> implementing interfaces, or anything like that - I'm kinda worried to see how
> deep the rabbit hole goes :|. All of the those are going to be necessary to be
> of much use.
> 
> Another option is to introduce new keywords, like
> clrclass/clrstruct/clrinterface. The code would no longer be "true"
> Python, but since you're inheriting from a .NET class, it's unlikely it would run
> on any other Python anyway. IT also makes it crystal clear to the compiler
> what you want. I doubt I'd want to introduce that into the 2.7-series though;
> it would likely be 3.0 only.
> 
> - Jeff
> 
> On Fri, Jul 6, 2012 at 7:34 AM, Slide <slide.o.mix at gmail.com> wrote:
> > I ported the pyc.py script to use IKVM.Reflection instead of
> > System.Reflection.Emit. It turns out some of the things (win32icon)
> > are MUCH easier to do with IKVM.Reflection. I attached the ported
> > version to [1] if people would like to give it a try. Let me know if
> > you see any issues and if not, I'll go ahead and commit this version.
> > Please don't file issues on CodePlex for this version since its not
> > part of the codebase yet. Please just drop me an email with any
> > problems you run into. There are lots more things that can be done
> > with IKVM.Reflection (compile for different runtimes, unmanaged
> > resources, etc) that are MUCH harder (or impossible) to do with
> > System.Reflection.Emit, so hopefully we can get this included in one
> > of the next releases.
> >
> > Thanks,
> >
> > slide
> >
> > 1 - http://ironpython.codeplex.com/workitem/22138
> >
> > --
> > Website: http://earl-of-code.com
> > _______________________________________________
> > Ironpython-users mailing list
> > Ironpython-users at python.org
> > http://mail.python.org/mailman/listinfo/ironpython-users
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
> 
>