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....@python.org > [mailto:ironpython-users-bounces+dinov=microsoft....@python.org] On > Behalf Of Jeff Hardy > Sent: Friday, July 06, 2012 8:24 AM > To: Slide > Cc: ironpython-users@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....@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 > > _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org http://mail.python.org/mailman/listinfo/ironpython-users
