[IronPython] DataRows and IronPython 2.0 B3

[Dino Viehland]

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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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 <fuzzyman at voidspace.org.uk<mailto:fuzzyman at voidspace.org.uk>> 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
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20080623/09182a76/attachment.html>