We're planning on shipping 2.0 RTM sometime in the 2nd half of this year - but we don't have a firm date quite yet.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pigneri, Rocco Sent: Thursday, February 07, 2008 6:56 AM To: Discussion of IronPython Subject: Re: [IronPython] Exporting Python code as an assembly 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. 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. Thanks, Rocco ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 :(. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>
_______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
