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:* [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 L. > > *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 > _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com