Thanks for reporting this - it's definitely a big regression. We switched ObjectOperations from using IOldDynamicObject to IDynamicObject and it looks like we missed a spot that needed to be changed (we need to manually insert the conversions ourselves now). For the time being you can just call the object version of GetMember and then call ConvertTo<T> on that.
I've opened a bug on CodePlex - http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=18595 I've got a fix for the other regression as well so hopefully that one will be in a source update this week. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Eloff Sent: Saturday, September 20, 2008 9:30 AM To: Discussion of IronPython Subject: [IronPython] Operations.GetMember<x> in b5 Hi, I'm noticing that GetMember cannot perform the casts it used to even two weeks ago. Is there some other function I should be using or something I should know about this? Tuples and lists of strings cannot be cast to IEnumerable<String> anymore, python functions cannot be cast to Func<...> or Action<...> delegates anymore. I got around the strings case by wrapping the python list in List<str>(), which indicates that internally IronPython has no difficulty converting to IEnumerable<String> since that's what the List constructor takes. Not really sure what to do about the function casts, what's the recommended way to expose Python functions and methods to C#? GetMember<Func<...>> seems to explode in too many ways now with the delegate regressions for instance methods and now this. -Dan _______________________________________________ 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
