Dear Dean, et al,
Dean Sturtevant wrote:
>I have a question as to the "type_code" column in the .description
>attribute of the Cursor object.
>
>How do you recommend a programmer get the meaning of a type_code? The
>documentation isn't clear on this.
>
>
>
As I see it (and I am probably wrong, but it may give the others on this
list something to refine as verses construct for themself), the
specification does a little bit of hand waving and a bunch of
indirection for the purpose of building a mapping between what types the
databases use and the types in Python. The requirement says that
.description must have a seven item sequence for each result column.
That should be simple enough. The second item in each of these is the
type_code you ask about. Skip ahead to the sections on "Type Objects
and Constructor" and "Implementation Hints for Module Authors". The
real requirement on type codes, as I understand it, is that if the
type_code in the .description matches (compares as equal) to the .STRING
attribute of the module then the value returned for that column (in say
a .fetchone()) will satisfy isinstance(foo,'str'), and similarly for
.BINARY, .NUMBER, .DATETIME, and .ROWID (although I can not tell you
what python type to use for that last one). The constructor functions
that are required for objects of these types are supposed to enable your
programs to be compare results with known values or to insert known
values into the tables. However, the actual technique that the
implementor uses to provide this functionality is unspecified.
Maybe I have it wrong and matching .STRING will not imply
isinstance(foo,'str) but rather that foo can be operated on or used
where a string would be needed without raising an exception. And a
.NUMBER can be used where a long or a float would be required and python
can convert it appropriately.
The specification does go quite a bit further in describing what is
required for values with type_code == .DATETIME in that it even suggests
a implementation, "those defined in the mxDateTime package". But even
here the implentor is allowed to use any underlying representation that
will give a similar appearance (with regard to comparing against or
operating with values produced by the constructor functions). (I chose
to use the datetime module instead of the mxDateTime module for my
interface.)
I hope that this is at least a step in the right direction.
>Thanks -
>
>Dean Sturtevant
>
>_______________________________________________
>DB-SIG maillist - DB-SIG@python.org
>http://mail.python.org/mailman/listinfo/db-sig
>
>
Thank you,
Arthur Protin
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
