[IronPython] Odd behaviour for unknown property

Dino Viehland dinov at exchange.microsoft.com
Fri Aug 3 00:23:00 CEST 2007

This is a bug - I've got a fix for it so it'll be in the next release.

If you want to know the details: the reason why it only affects user objects is that normal objects and user objects actually go through two wildly different code paths.  The user types are all instances of IDynamicObject whose implementation lives in UserTypeOps.cs.  Normal .NET objects for the most part get their members lookup handled by GetMemberBinderHelper in Microsoft.Scripting.  Both of these end up producing custom rules for use in a dynamic site which enables the member lookup to be quite fast.

Anyway, the implementation for user types is creating a rule which calls the wrong method to make the error.  It calls an overload that takes object, SymbolId and should get the type name and call the string, SymbolId overload.

Thanks for the report!

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell
Sent: Thursday, August 02, 2007 2:48 PM
To: Discussion of IronPython
Subject: [IronPython] Odd behaviour for unknown property

Oh that subject line is clumsy....

Is this a bug (2.0A3)?

import clr

from System import *
from System.Windows.Forms import *

class LDForm(Form):
    def __init__(self):

#This reports an AttributeError the method as read only.
test = LDForm()
print test.Idontexist

#This reports an AttributeError method as not existing as expected.
test = Form()
print test.Idontexist

Not sure if this is related to using or subclassing .Net objects - its
just what I was using at the time.


Davy Mitchell
Blog - http://www.latedecember.co.uk/sites/personal/davy/
Twitter - http://twitter.com/daftspaniel
Skype - daftspaniel
Users mailing list
Users at lists.ironpython.com

More information about the Ironpython-users mailing list