To be honest, some of the stuff in pyc would be a little easier in C# (which is strange I know), so creating IronPython.Compiler (or something similar) would be pretty nice for upkeep reasons. I would recommend we stick with the nomenclature that exists and have something like ipyc.exe for the executable, but this may be jumping the gun. I can take a stab at putting something together for that based on what exists in pyc.py.
On Fri, Jul 6, 2012 at 8:24 AM, Jeff Hardy <jdha...@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....@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 -- Website: http://earl-of-code.com _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org http://mail.python.org/mailman/listinfo/ironpython-users
