On May 2, 2007, at 8:47 AM, Art Protin wrote: > I am considering yet another extension to my driver. I especially > like the way that the methods cursor.fetch...() return lists of > objects > of the right type and the user of the API (the application) does not > need separate methods, one for each type, to fetch individual columns. > However, in the debugging of our JDBC driver I find that there is > some merit in getting the data, any of the data, as strings, which > just > happens to be the format that our database uses to pass them. > Thus, there are two aspects where you could now influence my > implementation: >
since its essentially an exposure of the implementation details of the underlying network conversation, and the use case youve found in JDBC is one of debugging, why not instead allow a hook for a debugging function that intercepts network traffic in response to normal fetchone()/fetchXXX() calls ? i cant see any reason an application would want to receive the network traffic directly under normal use (since the details of network conversations change with new releases and backends). _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
