-
Thanks - I've made the fix locally and will commit it after I next test the build.
2009-11-11 01:15:03 UTC in Python for Windows extensions
-
mhammond committed patchset 4027 of module pywin32 to the Python for Windows extensions CVS repository, changing 2 files.
2009-10-15 05:31:26 UTC in Python for Windows extensions
-
sounds reasonable - please consider sending a patch...
2009-09-29 10:00:08 UTC in Python for Windows extensions
-
mhammond committed patchset 4026 of module pywin32 to the Python for Windows extensions CVS repository, changing 3 files.
2009-09-27 12:04:31 UTC in Python for Windows extensions
-
pywin32 has moved to datetime objects in Python 3.x, so differences are expected, particularly when printing dates and times. This was a design decision and can't be fixed.
2009-09-17 22:51:31 UTC in Python for Windows extensions
-
Sorry, this is a limitation of the PyGILState API used by pywin32; pywin32 will never be able to play with the multiple interpreter API, nor work correctly with multiple interpreter initializations and cleanups.
2009-09-14 22:23:51 UTC in Python for Windows extensions
-
Yeah, that exception is a COM error thrown by labview. To be quite honest, I'm not sure what type win32com will attempt to pass in that case, but there is no simple COM type which can represent a complex number.
2009-09-12 01:50:51 UTC in Python for Windows extensions
-
COM doesn't define a complex type, so win32com doesn't either. I've no idea what LabVIEW would be expecting to be passed here - but I'm guessing it uses a simple array of 2 integers or floats, which is what makes you think win32com sometimes uses a tuple.
You probably need to ask the labview guys what they use to represent a complex number.
2009-09-12 00:08:58 UTC in Python for Windows extensions
-
and the next question is why utf8 is even being attempted here...
2009-09-02 23:33:40 UTC in Python for Windows extensions
-
Thanks for the followup!
2009-08-25 03:49:26 UTC in Python for Windows extensions
