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....@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@python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
_______________________________________________
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users
