[Ironpython-users] pyc port to IKVM.Reflection

[Slide]

I'm assuming this is the latest and greatest?

https://github.com/IronLanguages/main/blob/master/Languages/IronPython/Samples/ClrType/clrtype.py

On Fri, Jul 6, 2012 at 8:24 AM, Jeff Hardy <jdhardy at gmail.com> wrote:
> 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



-- 
Website: http://earl-of-code.com