pywin32-bugs Mailing List for Python for Windows Extensions (Page 2)
OLD project page for the Python extensions for Windows
Brought to you by:
mhammond
Menu
▾
▴
pywin32-bugs — Automated tracker notifications (not for bug reports!)
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(24) |
May
(19) |
Jun
(15) |
Jul
(43) |
Aug
(39) |
Sep
(25) |
Oct
(43) |
Nov
(19) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(21) |
Feb
(18) |
Mar
(14) |
Apr
(80) |
May
(56) |
Jun
(24) |
Jul
(30) |
Aug
(17) |
Sep
(36) |
Oct
(106) |
Nov
(38) |
Dec
(30) |
| 2005 |
Jan
(14) |
Feb
(14) |
Mar
(48) |
Apr
(28) |
May
(49) |
Jun
(23) |
Jul
(9) |
Aug
(13) |
Sep
(28) |
Oct
(21) |
Nov
(8) |
Dec
(26) |
| 2006 |
Jan
(56) |
Feb
(33) |
Mar
(33) |
Apr
(18) |
May
(16) |
Jun
(9) |
Jul
(24) |
Aug
(16) |
Sep
(14) |
Oct
(37) |
Nov
(38) |
Dec
(22) |
| 2007 |
Jan
(7) |
Feb
(16) |
Mar
(11) |
Apr
(15) |
May
(15) |
Jun
(8) |
Jul
(24) |
Aug
(26) |
Sep
(18) |
Oct
(11) |
Nov
(20) |
Dec
(1) |
| 2008 |
Jan
(19) |
Feb
(55) |
Mar
(7) |
Apr
(35) |
May
(66) |
Jun
(38) |
Jul
(26) |
Aug
(5) |
Sep
(25) |
Oct
(25) |
Nov
(18) |
Dec
(18) |
| 2009 |
Jan
(25) |
Feb
(38) |
Mar
(29) |
Apr
(25) |
May
(5) |
Jun
(11) |
Jul
(16) |
Aug
(16) |
Sep
(16) |
Oct
(1) |
Nov
(15) |
Dec
(33) |
| 2010 |
Jan
(13) |
Feb
(11) |
Mar
(1) |
Apr
(24) |
May
(26) |
Jun
(19) |
Jul
(22) |
Aug
(51) |
Sep
(38) |
Oct
(39) |
Nov
(25) |
Dec
(27) |
| 2011 |
Jan
(40) |
Feb
(31) |
Mar
(21) |
Apr
(42) |
May
(11) |
Jun
(16) |
Jul
(20) |
Aug
(14) |
Sep
(6) |
Oct
(8) |
Nov
(34) |
Dec
(7) |
| 2012 |
Jan
(60) |
Feb
(24) |
Mar
(6) |
Apr
(28) |
May
(41) |
Jun
(15) |
Jul
(14) |
Aug
(25) |
Sep
(30) |
Oct
(18) |
Nov
(30) |
Dec
(9) |
| 2013 |
Jan
(3) |
Feb
(8) |
Mar
(17) |
Apr
(23) |
May
(34) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2013-05-06 08:21:36
|
Patches item #3609017, was opened at 2013-03-25 07:39 Message generated for change (Comment added) made by sschukat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3609017&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Provide enums dynamically Initial Comment: In COM enums are transported as integers and hence hard to use for a programmer, which always has to map these numbers to comprehensive names. Since the enums are only available in typelibraries a wrapper had to be generated (makepy, gencache) to use them. There was no way that a enum could be used dynamically the same way a a COM object. The patch provides a way to use enums dynamically without generating a wrapper. So it is easy to use from a programmers viewpoint. The enum implementation used metaclasses so that the representation of the enum is always in a readable form and the enums are provided via members of enum classes. Used typelibraries are scanned inclusive their dependencies. >>> from win32com.client import Enums >>> from win32com.client import Dispatch >>> Word = Dispatch("Word.Application") >>> constants = Enums(Word) >>> constants.CertificateDetail.certdetIssuer <certdetIssuer 2> >>> print constants.CertificateDetail.certdetIssuer certdetIssuer >>> constants.CertificateDetail.certdetIssuer + 2 4 This enums class is used for over a year in our Python distribution and tested against Python 2.7.3 and Python 3.2.3 ---------------------------------------------------------------------- >Comment By: Stefan Schukat (sschukat) Date: 2013-05-06 01:21 Message: Actually the code was developed with Python 2.5 and then tested with 2.7.4 and 3.2, so backward compatibility should be no issue. The extra code in the str function is due to the use cases that in a GUI or with an print the user should be able to see the enum names and not the values (e.g. in a combobox). With the str utility function the developer must not make it own mapping for the display. The repr function is overwritten because a simple integer value (which would be valid for the eval function) would not represent the originally used enum item. Hence I used the angle bracket notation to show the enum named and integer value. In addition a REPL situation it is easier to determine the value of an enum >>> from win32com.client import Dispatch, Enums >>> App = Dispatch("Word.Application") >>> constants = Enums(App) >>> Doc = App.Documents.Add() >>> print constants.WdShowFilter(Doc.FormattingShowFilter) wdShowFilterFormattingRecommended >>> print constants.WdLineEndingType(Doc.TextLineEnding) wdCRLF >>> constants.WdLineEndingType(Doc.TextLineEnding) <wdCRLF 0> The arbitrary integer comment I don't understand, the valid enum values are encoded in the _names attribute. All other values lead to an unknown element, which is not added to the internal list. During the writing I found a bug in the str methods of the enum and bitmask classes. Fix is added to the patch queue and added the diff as file. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-05-05 18:25 Message: You might need to sell this one some more. I see that having constants from dynamic objects is a win, but all the other behaviour seems of questionable utility, especially given the size of the additional code (eg, why is that repr or print a win given it would be quite obvious to the developer without them, why can arbitrary integers be added to enums, etc) I'd be very happy with a patch that extended the existing simple-to-understand "constants" to work with dynamic objects though. Also note that pywin32 works with Python 2.5 and later, so code that works only in 2.7+ wouldn't be acceptable (although I haven't checked to see what the min version this code actually does work with) ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-05-03 06:20 Message: Added the patch with pep8 checked source and unit tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3609017&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-05-06 01:25:14
|
Patches item #3609017, was opened at 2013-03-25 07:39 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3609017&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Provide enums dynamically Initial Comment: In COM enums are transported as integers and hence hard to use for a programmer, which always has to map these numbers to comprehensive names. Since the enums are only available in typelibraries a wrapper had to be generated (makepy, gencache) to use them. There was no way that a enum could be used dynamically the same way a a COM object. The patch provides a way to use enums dynamically without generating a wrapper. So it is easy to use from a programmers viewpoint. The enum implementation used metaclasses so that the representation of the enum is always in a readable form and the enums are provided via members of enum classes. Used typelibraries are scanned inclusive their dependencies. >>> from win32com.client import Enums >>> from win32com.client import Dispatch >>> Word = Dispatch("Word.Application") >>> constants = Enums(Word) >>> constants.CertificateDetail.certdetIssuer <certdetIssuer 2> >>> print constants.CertificateDetail.certdetIssuer certdetIssuer >>> constants.CertificateDetail.certdetIssuer + 2 4 This enums class is used for over a year in our Python distribution and tested against Python 2.7.3 and Python 3.2.3 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-05-05 18:25 Message: You might need to sell this one some more. I see that having constants from dynamic objects is a win, but all the other behaviour seems of questionable utility, especially given the size of the additional code (eg, why is that repr or print a win given it would be quite obvious to the developer without them, why can arbitrary integers be added to enums, etc) I'd be very happy with a patch that extended the existing simple-to-understand "constants" to work with dynamic objects though. Also note that pywin32 works with Python 2.5 and later, so code that works only in 2.7+ wouldn't be acceptable (although I haven't checked to see what the min version this code actually does work with) ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-05-03 06:20 Message: Added the patch with pep8 checked source and unit tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3609017&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-05-06 01:13:55
|
Patches item #3612570, was opened at 2013-05-03 06:51 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3612570&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Determine type of interface Initial Comment: If you are using dynamic dispatch you cannot determine the type of an interface in an easy way. This patch adds two methods which returns the name of the interface of an dynamic object. With this a basic type check could be done for an interface. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-05-05 18:13 Message: I'm not that keen on this. In general, I don't see there is demand for these functions (eg, I don't recall ever seeing a mailing-list question asking how this might be done, there seems nothing in pywin32 itself which would want to use it, and I've never personally come across the need for it). Regarding the code itself: * New code should use pep8 * GetComIdentity() is a misleading name - the "identity" of a COM object is defined as the address of the pointer returned by a QI for IUnknown, so people familiar with COM will possibly be confused. GetDefaultInterfaceName would seem a better choice if this was to be implemented at all. * IsTypeOf() seems misleading - if I already have an object which has been QI'd to the non-default interface, it seems the function will return False when passed that interface name. If these make sense to your app/toolkit, they should probably be defined in your app/toolkit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3612570&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-05-03 13:51:35
|
Patches item #3612570, was opened at 2013-05-03 06:51 Message generated for change (Tracker Item Submitted) made by sschukat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3612570&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Determine type of interface Initial Comment: If you are using dynamic dispatch you cannot determine the type of an interface in an easy way. This patch adds two methods which returns the name of the interface of an dynamic object. With this a basic type check could be done for an interface. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3612570&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-05-03 13:20:15
|
Patches item #3609017, was opened at 2013-03-25 07:39 Message generated for change (Comment added) made by sschukat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3609017&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Provide enums dynamically Initial Comment: In COM enums are transported as integers and hence hard to use for a programmer, which always has to map these numbers to comprehensive names. Since the enums are only available in typelibraries a wrapper had to be generated (makepy, gencache) to use them. There was no way that a enum could be used dynamically the same way a a COM object. The patch provides a way to use enums dynamically without generating a wrapper. So it is easy to use from a programmers viewpoint. The enum implementation used metaclasses so that the representation of the enum is always in a readable form and the enums are provided via members of enum classes. Used typelibraries are scanned inclusive their dependencies. >>> from win32com.client import Enums >>> from win32com.client import Dispatch >>> Word = Dispatch("Word.Application") >>> constants = Enums(Word) >>> constants.CertificateDetail.certdetIssuer <certdetIssuer 2> >>> print constants.CertificateDetail.certdetIssuer certdetIssuer >>> constants.CertificateDetail.certdetIssuer + 2 4 This enums class is used for over a year in our Python distribution and tested against Python 2.7.3 and Python 3.2.3 ---------------------------------------------------------------------- >Comment By: Stefan Schukat (sschukat) Date: 2013-05-03 06:20 Message: Added the patch with pep8 checked source and unit tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3609017&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-05-03 07:57:03
|
Patches item #3612557, was opened at 2013-05-03 00:57 Message generated for change (Tracker Item Submitted) made by sschukat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3612557&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for objects from 64Bit longs variant Initial Comment: The conversion from a Python object to a VARIANT supports the data types VT_I8 and VT_UI8, the conversion from a VARIANT to a Python object is not supported. This patch adds the conversion from VT_I8 and VT_UI8 to a corresponding Python object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3612557&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-05-03 07:46:27
|
Bugs item #3612556, was opened at 2013-05-03 00:46 Message generated for change (Tracker Item Submitted) made by sschukat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612556&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Memory Leak in Safearray Conversion Initial Comment: In the method PyCom_PyObjectFromSAFEARRAYDimensionItem elements are retrieved via the SafeArrayGetElement method. The SafeArrayGetElement method always returns a copy of the internal data. In case of BSTR, IDispatch and IUnkown these copies are not freed or attached to a Python object. This patch attaches the returned values to the corresponding Python objects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612556&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-05-03 07:36:30
|
Patches item #3612555, was opened at 2013-05-03 00:36 Message generated for change (Tracker Item Submitted) made by sschukat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3612555&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Explicit conversion from PyLong to Variant Initial Comment: Since Python an arbitrary length long it is not easy to determine which VARIANT type is suitable. This patch checks the sign and the size of the long value and converts the long in the following way x < LLONG_MIN --> VT_R8 LLONG_MIN <= x < LONG_MIN --> VT_I8 LONG_MIN <= x < LONG_MAX --> VT_I4 LONG_MAX < x <= ULONG_MAX --> VT_UI4 ULONG_MAX < x <= LLONG_MAX --> VT_I8 LLONG_MAX < x <= ULLONG_MAX --> VT_UI8 ULLONG_MAX < x --> VT_R8 which adds the conversion to VT_UI8 and is different from the current way: x < LLONG_MIN --> VT_R8 LLONG_MIN <= x < LONG_MIN --> VT_I8 LONG_MIN <= x < LONG_MAX --> VT_I4 LONG_MAX < x <= ULONG_MAX --> VT_UI4 ULONG_MAX < x <= LLONG_MAX --> VT_I8 LLONG_MAX < x --> VT_R8 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3612555&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-05-02 05:35:01
|
Bugs item #3612200, was opened at 2013-04-29 07:41 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612200&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Crash in Python COM Server is Python was shutdown Initial Comment: If a Python implemented COM object is referenced by a client longer than lifetime of the Python runtime the hosting process crashes if during the release of the COM object Python functions are accessed. This is fixed by a check if Python is still initialized in the process. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-05-01 22:35 Message: fair enough - the patch is low enough risk that I'm fine with it (but probably with an updated comment that summarizes some of the discussion in this issue (eg, that we are specifically guarding against .NET's Release-only GC at program exit) ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-05-01 22:27 Message: The RCW (runtime callable wrapper) in . NET only calls release during the garbage collecting process and no other methods. Since we are using internal COM objects from the embedded Python interpreter we cannot avoid finalizing Python, These wrappers would keep the process alive due to reference counting. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-05-01 22:07 Message: Is there anything preventing the GC of an object indirectly causing code to run which may invoke a method on a COM object (eg, a "Quit()" method or similar) before the final release? What I'm trying to avoid is fixing this one case when it's possible other nasty things could still happen in non-trivial cases. Can you simply avoid finalizing Python completely? The process is going down, so it's not going to cause leaks etc. ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-05-01 22:02 Message: We are finalizing the embedded Python interpreter during shutdown of the process. This is a timing behavior since the garbage collector of .NET runs in a separate thread it could happen, that the collection of the last remaining objects is after the Py_Finalize in the main thread. Since the Python COM objects share the embedded interpreter inside a process the lifetime of the interpreter engine is not controlled by the Python COM objects but by the embedded interpreter. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-04-30 16:11 Message: But who is finalizing Python, and why are they doing it too early? ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-04-30 13:04 Message: This error happens in a mixed C++, Python and .NET application. A reference to a Python implemented COM object is held by a RCW in .NET. When the process exits Python is finalized but the COM object is held alive in the garbage collector of .NET. When a collection takes place after that the Python COM object could not access any Python function. So it is not a general problem, but a specific problem with the memory management of .NET for COM objects. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-04-29 23:34 Message: Can you give some details on how Python can become uninitialized at this time? pywin32 never finalizes Python, and I expect that if it was finalized while COM objects were alive we would have far more problems than just this one (eg, if rather than the object being destructed it instead attempt to make a "normal" call things would go pear-shaped pretty quickly I'd expect) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612200&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-05-02 05:27:50
|
Bugs item #3612200, was opened at 2013-04-29 07:41 Message generated for change (Comment added) made by sschukat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612200&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Crash in Python COM Server is Python was shutdown Initial Comment: If a Python implemented COM object is referenced by a client longer than lifetime of the Python runtime the hosting process crashes if during the release of the COM object Python functions are accessed. This is fixed by a check if Python is still initialized in the process. ---------------------------------------------------------------------- >Comment By: Stefan Schukat (sschukat) Date: 2013-05-01 22:27 Message: The RCW (runtime callable wrapper) in . NET only calls release during the garbage collecting process and no other methods. Since we are using internal COM objects from the embedded Python interpreter we cannot avoid finalizing Python, These wrappers would keep the process alive due to reference counting. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-05-01 22:07 Message: Is there anything preventing the GC of an object indirectly causing code to run which may invoke a method on a COM object (eg, a "Quit()" method or similar) before the final release? What I'm trying to avoid is fixing this one case when it's possible other nasty things could still happen in non-trivial cases. Can you simply avoid finalizing Python completely? The process is going down, so it's not going to cause leaks etc. ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-05-01 22:02 Message: We are finalizing the embedded Python interpreter during shutdown of the process. This is a timing behavior since the garbage collector of .NET runs in a separate thread it could happen, that the collection of the last remaining objects is after the Py_Finalize in the main thread. Since the Python COM objects share the embedded interpreter inside a process the lifetime of the interpreter engine is not controlled by the Python COM objects but by the embedded interpreter. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-04-30 16:11 Message: But who is finalizing Python, and why are they doing it too early? ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-04-30 13:04 Message: This error happens in a mixed C++, Python and .NET application. A reference to a Python implemented COM object is held by a RCW in .NET. When the process exits Python is finalized but the COM object is held alive in the garbage collector of .NET. When a collection takes place after that the Python COM object could not access any Python function. So it is not a general problem, but a specific problem with the memory management of .NET for COM objects. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-04-29 23:34 Message: Can you give some details on how Python can become uninitialized at this time? pywin32 never finalizes Python, and I expect that if it was finalized while COM objects were alive we would have far more problems than just this one (eg, if rather than the object being destructed it instead attempt to make a "normal" call things would go pear-shaped pretty quickly I'd expect) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612200&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-05-02 05:07:55
|
Bugs item #3612200, was opened at 2013-04-29 07:41 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612200&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Crash in Python COM Server is Python was shutdown Initial Comment: If a Python implemented COM object is referenced by a client longer than lifetime of the Python runtime the hosting process crashes if during the release of the COM object Python functions are accessed. This is fixed by a check if Python is still initialized in the process. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-05-01 22:07 Message: Is there anything preventing the GC of an object indirectly causing code to run which may invoke a method on a COM object (eg, a "Quit()" method or similar) before the final release? What I'm trying to avoid is fixing this one case when it's possible other nasty things could still happen in non-trivial cases. Can you simply avoid finalizing Python completely? The process is going down, so it's not going to cause leaks etc. ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-05-01 22:02 Message: We are finalizing the embedded Python interpreter during shutdown of the process. This is a timing behavior since the garbage collector of .NET runs in a separate thread it could happen, that the collection of the last remaining objects is after the Py_Finalize in the main thread. Since the Python COM objects share the embedded interpreter inside a process the lifetime of the interpreter engine is not controlled by the Python COM objects but by the embedded interpreter. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-04-30 16:11 Message: But who is finalizing Python, and why are they doing it too early? ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-04-30 13:04 Message: This error happens in a mixed C++, Python and .NET application. A reference to a Python implemented COM object is held by a RCW in .NET. When the process exits Python is finalized but the COM object is held alive in the garbage collector of .NET. When a collection takes place after that the Python COM object could not access any Python function. So it is not a general problem, but a specific problem with the memory management of .NET for COM objects. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-04-29 23:34 Message: Can you give some details on how Python can become uninitialized at this time? pywin32 never finalizes Python, and I expect that if it was finalized while COM objects were alive we would have far more problems than just this one (eg, if rather than the object being destructed it instead attempt to make a "normal" call things would go pear-shaped pretty quickly I'd expect) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612200&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-05-02 05:02:08
|
Bugs item #3612200, was opened at 2013-04-29 07:41 Message generated for change (Comment added) made by sschukat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612200&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Crash in Python COM Server is Python was shutdown Initial Comment: If a Python implemented COM object is referenced by a client longer than lifetime of the Python runtime the hosting process crashes if during the release of the COM object Python functions are accessed. This is fixed by a check if Python is still initialized in the process. ---------------------------------------------------------------------- >Comment By: Stefan Schukat (sschukat) Date: 2013-05-01 22:02 Message: We are finalizing the embedded Python interpreter during shutdown of the process. This is a timing behavior since the garbage collector of .NET runs in a separate thread it could happen, that the collection of the last remaining objects is after the Py_Finalize in the main thread. Since the Python COM objects share the embedded interpreter inside a process the lifetime of the interpreter engine is not controlled by the Python COM objects but by the embedded interpreter. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-04-30 16:11 Message: But who is finalizing Python, and why are they doing it too early? ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-04-30 13:04 Message: This error happens in a mixed C++, Python and .NET application. A reference to a Python implemented COM object is held by a RCW in .NET. When the process exits Python is finalized but the COM object is held alive in the garbage collector of .NET. When a collection takes place after that the Python COM object could not access any Python function. So it is not a general problem, but a specific problem with the memory management of .NET for COM objects. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-04-29 23:34 Message: Can you give some details on how Python can become uninitialized at this time? pywin32 never finalizes Python, and I expect that if it was finalized while COM objects were alive we would have far more problems than just this one (eg, if rather than the object being destructed it instead attempt to make a "normal" call things would go pear-shaped pretty quickly I'd expect) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612200&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-04-30 23:11:10
|
Bugs item #3612200, was opened at 2013-04-29 07:41 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612200&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Crash in Python COM Server is Python was shutdown Initial Comment: If a Python implemented COM object is referenced by a client longer than lifetime of the Python runtime the hosting process crashes if during the release of the COM object Python functions are accessed. This is fixed by a check if Python is still initialized in the process. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-04-30 16:11 Message: But who is finalizing Python, and why are they doing it too early? ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-04-30 13:04 Message: This error happens in a mixed C++, Python and .NET application. A reference to a Python implemented COM object is held by a RCW in .NET. When the process exits Python is finalized but the COM object is held alive in the garbage collector of .NET. When a collection takes place after that the Python COM object could not access any Python function. So it is not a general problem, but a specific problem with the memory management of .NET for COM objects. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-04-29 23:34 Message: Can you give some details on how Python can become uninitialized at this time? pywin32 never finalizes Python, and I expect that if it was finalized while COM objects were alive we would have far more problems than just this one (eg, if rather than the object being destructed it instead attempt to make a "normal" call things would go pear-shaped pretty quickly I'd expect) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612200&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-04-30 20:04:10
|
Bugs item #3612200, was opened at 2013-04-29 07:41 Message generated for change (Comment added) made by sschukat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612200&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Crash in Python COM Server is Python was shutdown Initial Comment: If a Python implemented COM object is referenced by a client longer than lifetime of the Python runtime the hosting process crashes if during the release of the COM object Python functions are accessed. This is fixed by a check if Python is still initialized in the process. ---------------------------------------------------------------------- >Comment By: Stefan Schukat (sschukat) Date: 2013-04-30 13:04 Message: This error happens in a mixed C++, Python and .NET application. A reference to a Python implemented COM object is held by a RCW in .NET. When the process exits Python is finalized but the COM object is held alive in the garbage collector of .NET. When a collection takes place after that the Python COM object could not access any Python function. So it is not a general problem, but a specific problem with the memory management of .NET for COM objects. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-04-29 23:34 Message: Can you give some details on how Python can become uninitialized at this time? pywin32 never finalizes Python, and I expect that if it was finalized while COM objects were alive we would have far more problems than just this one (eg, if rather than the object being destructed it instead attempt to make a "normal" call things would go pear-shaped pretty quickly I'd expect) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612200&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-04-30 12:02:22
|
Bugs item #3612206, was opened at 2013-04-29 08:12 Message generated for change (Comment added) made by sschukat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612206&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Deadlock with Loader Lock and GIL Initial Comment: FormatMessage could implicit load libraries to read resource strings for the message formatting. For this the windows DLL loader lock is acquired. In an multithreaded application which makes use of native an Python threads a deadlock could happen if these two locks (Loader Lock, GIL) are acquired in wrong order. This fix releases the GIL before a call to FormatMessage is made. ---------------------------------------------------------------------- >Comment By: Stefan Schukat (sschukat) Date: 2013-04-30 05:02 Message: I provided a patch in the patch queue with the changes suggested. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-04-29 23:30 Message: This patch looks fine, but could you please remove the lines like "// code changed by ssc" - source control can tell us that (and if you upload a patch from a mercurial queue, you will be directly attributed for the change) Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612206&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-04-30 06:34:02
|
Bugs item #3612200, was opened at 2013-04-29 07:41 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612200&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Crash in Python COM Server is Python was shutdown Initial Comment: If a Python implemented COM object is referenced by a client longer than lifetime of the Python runtime the hosting process crashes if during the release of the COM object Python functions are accessed. This is fixed by a check if Python is still initialized in the process. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-04-29 23:34 Message: Can you give some details on how Python can become uninitialized at this time? pywin32 never finalizes Python, and I expect that if it was finalized while COM objects were alive we would have far more problems than just this one (eg, if rather than the object being destructed it instead attempt to make a "normal" call things would go pear-shaped pretty quickly I'd expect) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612200&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-04-30 06:30:57
|
Bugs item #3612206, was opened at 2013-04-29 08:12 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612206&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Deadlock with Loader Lock and GIL Initial Comment: FormatMessage could implicit load libraries to read resource strings for the message formatting. For this the windows DLL loader lock is acquired. In an multithreaded application which makes use of native an Python threads a deadlock could happen if these two locks (Loader Lock, GIL) are acquired in wrong order. This fix releases the GIL before a call to FormatMessage is made. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-04-29 23:30 Message: This patch looks fine, but could you please remove the lines like "// code changed by ssc" - source control can tell us that (and if you upload a patch from a mercurial queue, you will be directly attributed for the change) Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612206&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-04-29 23:29:40
|
Patches item #3612197, was opened at 2013-04-29 07:21 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3612197&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Add COM threads wrapper classes Initial Comment: COM requires a specific setup for a thread to function correctly. - Interface passing has to be done by marshaling - the thread has to be initialized for a specific apartment type - every create COM object has to be released before the thread has been uninitialized fro COM - STA thread join has to do message pumping This handling is tedious and requires specific knowledge. Hence this patch provides wrapper classes which takes care of the needed environment. These classes have the same interface as the standard threading.Thread classes and could be used in the same way. Unit tests are provided using Microsoft Word as COM server. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-04-29 16:29 Message: Thanks for the patch - in general this new module looks fine. Could you please upload unzipped .patch files - even in cases like these when only new files are created? Ideally, a patch exported by hg would be best so your name etc appears in the checkin. You might like to look into the "queues" extension/feature of hg. Also, whenever possible, the tests should not rely on some external tool being installed - eg, Word is not installed on any of my boxes, so these tests can't be run by me. We already have a number of test COM servers in the test suite, so using one of them would be best (explicitly using a CLSCTX flag if, eg, an out-of-process server is necessary) Re comthreads.py: * All imports should generally be at the top of the file, and there is no need to "del" the symbols. The only exception would be for imports that are only used in rare cases, but it appears that most of the modules will end up being imported by everyone who uses this module, so they should be at the top. * All files should end with line-end sequence. * One of the docstrings refers to "dSPACE base thread" which doesn't sound right. * It would be great if the docstring for the module demonstrates some example usage - ie, how the consumer of this module would use it. * For new code, we try and follow pep8 - eg, instance attributes, variable/arg names etc should not start with an upper-case letter and ideally not be camelCase. * def join(self, timeout): - it looks to me like the timeout will be "reset" each time a message appears - ie, a message arriving once every second would cause .join(2) to never return? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3612197&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-04-29 15:12:12
|
Bugs item #3612206, was opened at 2013-04-29 08:12 Message generated for change (Tracker Item Submitted) made by sschukat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612206&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Deadlock with Loader Lock and GIL Initial Comment: FormatMessage could implicit load libraries to read resource strings for the message formatting. For this the windows DLL loader lock is acquired. In an multithreaded application which makes use of native an Python threads a deadlock could happen if these two locks (Loader Lock, GIL) are acquired in wrong order. This fix releases the GIL before a call to FormatMessage is made. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612206&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-04-29 14:41:32
|
Bugs item #3612200, was opened at 2013-04-29 07:41 Message generated for change (Tracker Item Submitted) made by sschukat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612200&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Crash in Python COM Server is Python was shutdown Initial Comment: If a Python implemented COM object is referenced by a client longer than lifetime of the Python runtime the hosting process crashes if during the release of the COM object Python functions are accessed. This is fixed by a check if Python is still initialized in the process. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612200&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-04-29 14:21:41
|
Patches item #3612197, was opened at 2013-04-29 07:21 Message generated for change (Tracker Item Submitted) made by sschukat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3612197&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Add COM threads wrapper classes Initial Comment: COM requires a specific setup for a thread to function correctly. - Interface passing has to be done by marshaling - the thread has to be initialized for a specific apartment type - every create COM object has to be released before the thread has been uninitialized fro COM - STA thread join has to do message pumping This handling is tedious and requires specific knowledge. Hence this patch provides wrapper classes which takes care of the needed environment. These classes have the same interface as the standard threading.Thread classes and could be used in the same way. Unit tests are provided using Microsoft Word as COM server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3612197&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-04-29 14:05:35
|
Bugs item #3612178, was opened at 2013-04-29 03:23 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612178&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Tim Golden (tjgolden) Assigned to: Nobody/Anonymous (nobody) Summary: .h files not being generated from .mc Initial Comment: (This may be a duplicate of #3581717) A fresh hg checkout fails to build because changes to setup.py have caused .mc files to be built after the .cpp files for which the resulting .h files are needed. The attached brief patch fixes the problem (by simply reversing the order of the files). ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2013-04-29 07:05 Message: Thanks, patch applied ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612178&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-04-29 10:23:15
|
Bugs item #3612178, was opened at 2013-04-29 03:23 Message generated for change (Tracker Item Submitted) made by tjgolden You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612178&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tim Golden (tjgolden) Assigned to: Nobody/Anonymous (nobody) Summary: .h files not being generated from .mc Initial Comment: (This may be a duplicate of #3581717) A fresh hg checkout fails to build because changes to setup.py have caused .mc files to be built after the .cpp files for which the resulting .h files are needed. The attached brief patch fixes the problem (by simply reversing the order of the files). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612178&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-04-19 07:26:32
|
Bugs item #3611214, was opened at 2013-04-17 09:16 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3611214&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Dennis (rdsteed) Assigned to: Nobody/Anonymous (nobody) Summary: Bad error checking in win32Print.DocumentProperties Initial Comment: I'm trying to troubleshoot some problems I have using win3wPrint.DocumentProperties. I get strange results returned in DevModeOutput but no errors are raised. Possible solution: I think the problem is in win32Print.cpp. Lines of win32Print.cpp (current version after changeset 4299) 1346 rc=DocumentProperties(hwnd, hprinter, devicename, dmoutput, dminput, mode); 1347 if (ret < 0) 1348 PyWin_SetAPIError("DocumentProperties"); In line 1347, ret is not yet defined. The code should actually be testing for rc<0 : 1346 rc=DocumentProperties(hwnd, hprinter, devicename, dmoutput, dminput, mode); 1347 if (rc < 0) 1348 PyWin_SetAPIError("DocumentProperties"); ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2013-04-19 00:26 Message: Fix has been applied ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2013-04-17 11:31 Message: Thanks for spotting that. I'll get the fix in place before the next release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3611214&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-04-18 00:18:04
|
Bugs item #3611243, was opened at 2013-04-17 16:49 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3611243&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Gary Bloom (bloominator) Assigned to: Nobody/Anonymous (nobody) Summary: Importing win32ui causes hang on exit Initial Comment: Importing win32ui in a simple .py program causes a hang on exit with pywin32-218. This hang occurs under Python 2.6.7, 2.7.4, and 3.1.4. It does not occur under 3.2.4 and 3.3.1. I currently only test using 32-bit Python. The last-known good pywin32 version on Py2.6 was pywin32-212. Some regression was introduced in pywin32-213 and has existed since then (still in pywin32-218), causing this system hang on exit on Python builds 2.6 and 2.7. Testing Python 3, I see that the issue exists in Pythons 3.0 and 3.1 but goes away in 3.2 and 3.3. The following Python code snippet demonstrates a hang on exit: ################################# import Tkinter import win32ui #including this library causes hang on exit master = Tkinter.Tk() #Label not needed to reproduce hang Tkinter.Label(text=" Will hang on exit if win32ui has been imported").pack() master.mainloop() ################################# This bug is preventing me from upgrading my build to Python 2.7, because: 1) I need pywin32, 2) pywin32-212 is the last version that does not have the hang regression, and 3) pywin32-212 Windows builds stop at Python 2.6. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-04-17 17:18 Message: Sadly Tkinter and win32ui have played poorly together, in various ways, basically forever. This is just the nature of the beast when multiple things want to control the main event loop. I've no intention of trying to fix this, but would accept patches that make things suck less then they currently do. ---------------------------------------------------------------------- Comment By: Gary Bloom (bloominator) Date: 2013-04-17 16:54 Message: I should mention that I only have tested running 32-bit Python on 64-bit Windows 7. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3611243&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
