[Ironpython-users] pyc port to IKVM.Reflection

[Jeff Hardy]

On Fri, Jul 6, 2012 at 11:40 AM, Dino Viehland <dinov at microsoft.com> wrote:
> 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).

I actually forgot about attributes. That is pretty important :).

>
> 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.

I'm not sure I want to down that route, except as a prototype.
IronPython already has the biggest breaking change (Unicode), so
porting from 2.7 -> 3.0 shouldn't be too bad.

>
> 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.

That's pretty much exactly it. I don't want to compile all of the
Python code; I just want to produce CLS-compliant classes that call
the Python code, so that I can reference them.

Android has some limitations around what you can inherit from. It
requires some AOT steps to inherit from Java classes ... which
includes all of the UI widgets. I was hand-crafting the wrappers that
just forward to Python code, but I figured there had to be an easier
way, and pyc.py (or similar) seems like the ticket.

- Jeff