[Ironpython-users] pyc port to IKVM.Reflection
m.schaber at 3s-software.com
Mon Jul 9 08:41:20 CEST 2012
> Von: Jeff Hardy
> On Fri, Jul 6, 2012 at 11:40 AM, Dino Viehland <dinov at microsoft.com>
> > 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 :).
For a complete solution, we do not only need the ability to expose .NET attributes for types and methods, there needs to be a way to specify them on the assembly level. In C#, they usually reside in the AssemblyInfo.cs file.
Apart from the basic AssemblyTitle, AssemblyVersion & Co, some frameworks use custom attributes like PluginGuid.
> > 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.
That seems like a sensible way. Most of those frameworks use either fully qualified class name or custom attributes, most of the time in combination with the list of base classes and implemented interfaces.
They don't concern about the implementation details, only the "surface" of the class needs to fit their expectations.
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
More information about the Ironpython-users