[IronPython] Exporting Python code as an assembly

Thu Feb 7 16:19:07 CET 2008

Pigneri, Rocco wrote:
> Dino,
> Thanks for the insight. That helpls a lot. Too bad that we still won't 
> be able to create IP types with the DLR in 2.0. I was hoping that that 
> would be a feature.
>
Did you see this article on future CLR/DLR integration?

http://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx

> By the way, do you guys have an idea of when 2.0 final will be 
> released? Or at least an idea of what stages it has left to go through 
> (how many more alpha stages, beta releases, RC's)? I couldn't find 
> this on CodePlex.
'They' did say, not long ago, that IP 2 final would be sometime around 
the end of this year and *hopefully* coincide with a DLR 1.0 final.

Michael
http://www.manning.com/foord

> Thanks,
> Rocco
>
> ------------------------------------------------------------------------
> *From:* users-bounces at lists.ironpython.com 
> [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Dino Viehland
> *Sent:* Wednesday, February 06, 2008 3:54 PM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Exporting Python code as an assembly
>
> The extra __’s are expected. When we enabled this in 1.1.1 we didn’t 
> want to significantly alter the experience between 1.1 and 1.1.1. The 
> problem with 1.1 was that if the caller passed in an attribute to 
> filter by (DataGridView passes in BrowsableAttribute) we would say 
> “attributes? We don’t have attributes, so you’ll get an empty 
> collection”. In 1.1.1 we’ll return just about anything if browsable is 
> set. In 2.0, where we have a little more leeway to change things, 
> we’re more aggressive about filtering out things you probably don’t 
> want to see. You can always not auto-generate the columns and you’ll 
> get the columns you presumably want.
>
> The AllowNew is going to be an unfortunate limitation – Python type 
> instances can’t (easily) be created by anyone except for the Python 
> runtime. The reason is we need to pass a PythonType object into the 
> contructor so the object knows it’s type in the Python world. So we 
> probably can’t do much about this one L.
>
> *From:* users-bounces at lists.ironpython.com 
> [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Pigneri, Rocco
> *Sent:* Wednesday, February 06, 2008 12:47 PM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Exporting Python code as an assembly
>
> Dino,
>
> Ah ha! Well, it didn't work under 1.1, but under 1.1.1, it worked 
> nearly right out of the box. When I used a static interface under 1.1, 
> I only got the static properties in the DataGridView. However, under 
> 1.1.1, I am getting a whole extra slew of information in my Grids 
> (__weakref__, __doc__, the hidden values, the properties themselves, 
> every function in the type) when I turn on AutoColumnGenerate. Is this 
> what I should be expecting?
>
> Also, it seems that if I turn on user creation of new elements 
> (BindingList.AllowNew = True), then the component crashes with an 
> error stating that it cannot find the constructor for my type, whether 
> or not I have defined it. Is this also to be expected or not?
>
> Thank you,
>
> Rocco Pigneri
>
> ------------------------------------------------------------------------
>
> *From:* users-bounces at lists.ironpython.com 
> [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Dino Viehland
> *Sent:* Tuesday, February 05, 2008 4:55 PM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Exporting Python code as an assembly
>
> Data binding isn’t working for you? We have support for this via 
> CustomTypeDescriptors which describe the Python objects and we have 
> some test cases to verify it works. Note it was broken before 1.1.1 
> although it’s been working in 2.0 for a little while now. For example:
>
> import clr
>
> clr.AddReference('System.Windows.Forms')
>
> import System.Windows.Forms as SWF
>
> import System
>
> class AgeQualifier(object):
>
> def __get__(self, instance, ctx):
>
> if instance.Age < 13: return 'young'
>
> if instance.Age < 20: return 'teen'
>
> if instance.Age < 30: return 'twenties'
>
> if instance.Age < 40: return 'thirties'
>
> if instance.Age < 50: return 'forties'
>
> return 'old'
>
> SAMPLE_DATA = [('Joe', 23, 'twenties'), ('Bob', 8, 'young'), 
> ('Thomas', 32, 'thirties'), ('Patrick', 41, 'forties'), ('Kathy', 19, 
> 'teen'), ('Sue' , 77, 'old'),]
>
> class Person(System.Object):
>
> def __init__(self, name, age):
>
> self._name = name
>
> self._age = age
>
> def get_name(self):
>
> return self._name
>
> def set_name(self, value):
>
> self._name = value
>
> Name = property(get_name, set_name)
>
> def get_age(self):
>
> return self._age
>
> def set_age(self, value):
>
> self._age = value
>
> Age = property(get_age, set_age)
>
> AgeDescription = AgeQualifier()
>
> class Form(SWF.Form):
>
> def __init__(self):
>
> SWF.Form.__init__(self)
>
> self._people = people = []
>
> for name, age, ignored in SAMPLE_DATA:
>
> people.append(Person(name, age))
>
> grid = SWF.DataGridView()
>
> grid.AutoGenerateColumns = True
>
> grid.DataSource = people
>
> grid.Dock = SWF.DockStyle.Fill
>
> self.grid = grid
>
> self.Controls.Add(grid)
>
> form = Form()
>
> SWF.Application.Run(form)
>
> *From:* users-bounces at lists.ironpython.com 
> [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Pigneri, Rocco
> *Sent:* Tuesday, February 05, 2008 9:15 AM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Exporting Python code as an assembly
>
> Curt,
>
> This is a great feature and was one of the first features that I 
> investigated when I first got my hands on IP.
>
> I see an immediate need for this feature in using data binding with 
> Windows Forms controls. Many controls (such as DataGridView and 
> ListView) reflect over the properties of bound objects in order to 
> display this data dynamically with no programmer setup. Because IP 
> types are dynamic, WinForms cannot find any properties to bind and 
> creates an "empty" object. In order to use these features now, I must 
> create static interfaces with the required properties in a separate 
> assembly and then inherit that interface whenever I bind to business 
> objects.
>
> To make using these UI controls easier, it would be great if property 
> statements could be turned into static properties either automatically 
> or via a flag. It seems that IP already matches properties to the 
> correct static getter/setter as defined in the interfaces so this 
> should be a reasonable request. This staticization would remove the 
> need for the separate static interface.
>
> Another situation in which this would be really helpful--although less 
> critical--involves situations where I want to use a static tool on an 
> IP assembly (for example, I want to use NUnit to test my IP classes). 
> I say that this is not critical as a lot of tools already have 
> Python-specific versions available--PyUnit is a good example.
>
> Finally, would there be a way to simplify programmer work by providing 
> "standard" static creators that are turned on and off at a high level? 
> For example, programmers could use a "compiler" switch to turn all 
> functions into "void func(object, . . .)" and "object func(obj. . . 
> )". I see this being useful in situations such as using NUnit because 
> all that is really needed is the proper number of arguments and the 
> right function name (all of which are already known in Python). If 
> things then work the way that I think they work, you could then just 
> pass the objects into the correct comparators, and if they are the 
> right type, then the tests will run. Otherwise, you'll get an exception.
>
> Hope that helps,
>
> Rocco
>
> ------------------------------------------------------------------------
>
> *From:* users-bounces at lists.ironpython.com 
> [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Curt 
> Hagenlocher
> *Sent:* Monday, February 04, 2008 1:31 PM
> *To:* Discussion of IronPython
> *Subject:* [IronPython] Exporting Python code as an assembly
>
> After a bit of spare-time hacking this weekend, I've got a 
> "proof-of-concept" program that takes a Python class and exports it as 
> a (statically-defined) assembly. It uses Pythonic function annotations 
> to signal attributes and input and output types to the wrapper 
> generator. You end up with something like this
>
> def Test(object):
>
> @ClrAttribute(Xunit.FactAttribute)
>
> def WorthlessTest(self):
>
> Xunit.Assert.Equal[type(1)](1, 1)
>
> @ClrAccepts(System.String, System.Int32)
>
> @ClrReturns(System.Int32)
>
> def CalculateValue(self, s, i):
>
> return len(s) + i
>
> The program takes this source and spits out a DLL containing the class 
> "Test" which implements "WorthlessTest" and "CalculateValue". The 
> class itself contains a reference to the actual Python object, and 
> each of the public functions simply delegates to the Pythonic 
> implementation.
>
> I'm still working on cleaning up the source a little before releasing 
> it, but was wondering if anyone had some feedback on the design as 
> described so far. What should be changed or implemented in order for 
> this to be more useful to you?
>
> Thanks,
>
> -Curt
>
> --
>
> Curt Hagenlocher
>
> curt at hagenlocher.org <mailto:curt at hagenlocher.org>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>