Actually it's not related to the interfaces - DataRow implements no interfaces! Instead what it has is a default member which we of course map into __getitem__. And Python says that all things with __getitem__ can be enumerated by going from 0 until you get an exception.
In 2.0 we apparently support this conversion on user defined types but not on built-in .NET types. I'm actually doing some work now which will unify the .NET vs User-Defined type code paths so this will go away but I've opened bug #17142 to track this (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17142). That way afterwards we'll make sure we've got a test in place and it won't regress in the future. Now that being said you probably don't actually want to be doing this for performance reasons :). The way we know this iteration is complete is when an exception is thrown which is going to be bad for perf. Calling row.ItemArray is going to give you a real enumerable object which terminates w/o an exception so you may see better perf that way - of course that seems to make a copy of all the rows, so there's a trade-off to be made here... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher Sent: Monday, June 23, 2008 8:37 AM To: Discussion of IronPython Subject: Re: [IronPython] DataRows and IronPython 2.0 B3 It's very unlikely that this was intentional. I suspect that it's related to a change in the way we handle interfaces -- this wouldn't be the first unanticipated consequence of that change. :/ On Mon, Jun 23, 2008 at 8:30 AM, Michael Foord <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote: Note that we can fix it by iterating over 'row.ItemArray' instead, I just wondered if the breakage was intentional. Michael Foord Michael Foord wrote: Hello all, I'm further investigating potential compatibility issues with moving Resolver One to IronPython 2, and I've encountered a change in behaviour with respect to iterating over DataRows. The script below works in IronPython 1, printing all the data in the rows. In IronPython 2.0 B3 it raises an exception. IronPython 1: C:\compile>c:\Binaries\ironpython\ipy.exe test_data.py 0 System.Data.DataRow 0 A Big Boy Did It and Ran Away 1 System.Data.DataRow 0 Affective Computing 2 System.Data.DataRow 0 Clear and Present Danger IronPython 2: C:\compile>c:\Binaries\ironpython2\ipy.exe test_data.py 0 <System.Data.DataRow object at 0x000000000000002B [System.Data.DataRow]> Traceback (most recent call last): File "test_data.py", line 29, in test_data.py TypeError: expected IEnumerator, got DataRow Test script: import clr clr.AddReference('System.Data') from System.Data import DataSet from System.Data.Odbc import OdbcConnection, OdbcDataAdapter connectString = ( "DRIVER={MySQL ODBC 3.51 Driver};" "blah blah blah" "OPTION=3;" ) query = "SELECT title FROM books WHERE price > 2 ORDER BY title" connection = OdbcConnection(connectString) adaptor = OdbcDataAdapter(query, connection) dataSet = DataSet() connection.Open() adaptor.Fill(dataSet) connection.Close() for rowIndex, row in enumerate(dataSet.Tables[0].Rows): print rowIndex, row for colIndex, data in enumerate(row): print ' ', colIndex, data Michael Foord http://www.ironpythoninaction.com/ _______________________________________________ Users mailing list [email protected]<mailto:[email protected]> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list [email protected]<mailto:[email protected]> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
