AW: Python2.6 + win32com crashes with unicode bug
SSchukat at dspace.de
Mon Nov 2 11:26:42 CET 2009
there is no problem in the file, but in the description of the Visio API. The place where the error occurs is during the definition
of the parameters of the corresponding Python methods. The information for the names comes from the typelibrary of visio. Probably there is a
non english name inside the typelibrary (MS used native names in early Office products) which then could not decoded to a correct Python name.
In my Version of Vsio OpenEx has two parameters called FileName and Flags. You have to look in your typelibrary, e.g. with OleView
http://www.microsoft.com/downloads/details.aspx?familyid=5233b70d-d9b2-4cb5-aeb6-45664be858b6&displaylang=en and check the parameters.
Von: python-list-bounces+sschukat=dspace.de at python.org [mailto:python-list-bounces+sschukat=dspace.de at python.org] Im Auftrag von GerritM
Gesendet: Freitag, 30. Oktober 2009 18:00
An: Terry Reedy
Cc: python-list at python.org
Betreff: Re: Python2.6 + win32com crashes with unicode bug
Terry Reedy schreef:
> GerritM wrote:
>> I have automated image generation with Python, win32com and Visio5.0.
>> This works well upto Python2.5 but fails with Python 2.6.
>> Short term solution is to return to 2.5 :-(.
>> I have reproduced the bug below with a minimum of Python lines. Below
>> the problem the working example from 2.5
>> kind regards, Gerrit
>> ---minimal session reproducing the bug---
>> d = v.Documents.OpenEx("D:/temp/test.vsd",8)
>> UnicodeDecodeError: 'ascii' codec can't decode byte 0x83 in position
>> 52: ordinal not in range(128)
> I suspect that 2.6 fixed the bug of allowing non-ascii chars when using
> the ascii codec. I would check to see if there is an 0x83 in
the string "D:/temp/test.vsd" itself does not contain any
>>> for c in "D:/temp/test.vsd":
print ord(c), " ",
68 58 47 116 101 109 112 47 116 101 115 116 46
118 115 100
(on my current Python 2.5 configuration)
The presumably binary file itself may contain any value, but I don't
expect Python or win32com to do anything with the file content...
There are explanations on internet that Windows uses internally 2
(incompatible) API's that cause poblems with Unicode based filenames. I
do something like that to be the problem in Python 2.6
kind regards, Gerrit
More information about the Python-list