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