[Ironpython-users] pyc port to IKVM.Reflection

Jimmy Schementi jschementi at gmail.com
Fri Jul 6 19:37:10 CEST 2012


> 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.

pyc in IronPython does as much compilation as possible ahead of time,
but because IronPython types don't map to static CLR types, it doesn't
generate the assembly to have matching static types. I'm not sure how
easy it is to do, as I think you'd basically be making every Python
type a built-in. Makes pyc closer to a static compiler, which isn't
really the intention. Plus, in true Python form, it seems this type of
control over the CLR type should be explicit (with clrtype.py) rather
than just happen for you when you run your code through pyc.py.

The use case for __clrtype__ is to emit specific static type
information from IronPython, but not require generating an assembly
before. For example, .NET attributes require an concrete CLR type or
method for the attribute to be applied to. However, IronPython does
not guarantee that each Python type or method maps to a static CLR
type/method, as emitting the static types are expensive and cannot be
disposed. __clrtype__ provides the ability to control the CLR type for
a specific Python class. clrtype.py contains a bunch of helpers
intended to make all this easier; generating a CLR type at runtime,
adding methods to it, adding attributes, etc. This applies to more
than just .NET attributes, though that was the most requested feature.
It enables Data Binding, or any code which uses Reflection in its
application model, like how ASP.NET MVC routes a HTTP request to a
specific method.

~Jimmy


On Jul 6, 2012, at 11:24 AM, Jeff Hardy <jdhardy at gmail.com> wrote:

> 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.


More information about the Ironpython-users mailing list