Unicode with win32com and makepy

Tim Roberts timr at probo.com
Sat Mar 30 00:31:56 EST 2002


Some time ago, I posted about a problem I was having accessing text fields
from an Access database using ADO via win32com.  I was getting an error
about characters with ordinals beyond 255.  Several suggestions were
offered, but none helped.

I dug in to this a bit more.  The problem can be traced into the Python
files generated by makepy.  I did a makepy on ADO 2.5.  About a third of
the way through that generated file, we find

    class Field(DispatchBaseClass):

which contains this:

         # str(ob) and int(ob) will use __call__
         def __str__(self, *args):
                 try:
                         return str(apply( self.__call__, args))
                 except pythoncom.com_error:
                         return repr(self)

If I try to fetch the contents of an Access field with an extended
character (e with an umlaut, in my case), the error happens in the "return
str(apply(..." line.  This is somewhat sensible, since it is being asked to
convert a character outside ASCII.

Several folks suggested I call unicode() to fetch the string value of the
field.  This does not work; the Field class does not contain a __unicode__
method, so Python calls __str__ instead, which fails.

My temporary workaround is to edit the generated Python (!) by adding a
__unicode__ method:

         def __unicode__(self, *args):
                 try:
                         return unicode(apply( self.__call__, args))
                 except pythoncom.com_error:
                         return repr(self)

Now, I can wrap unicode() around my field fetch, and it does fetch the
correct string.

Here's the question: what do we do in the long term?  Should makepy
generate a __unicode__ member every time it generates a __str__ member?
--
- Tim Roberts, timr at probo.com
  Providenza & Boekelheide, Inc.



More information about the Python-list mailing list