[IronPython] Exporting Python code as an assembly

[Pigneri, Rocco]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20080206/39ba5056/attachment.html>