|
From: SourceForge.net <no...@so...> - 2005-05-04 10:19:18
|
Patches item #1195096, was opened at 2005-05-04 12:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1195096&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Native access to SAFEARRAY with wrapper class Initial Comment: The conversion to/from SAFEARRAYs to tuples takes up a lot of time if the SAFEARRAYs are really big. Therefore I created a wrapper class which does not copy any data and just wraps the access to the underlying SAFEARRAY data. In addition to the performance improvements thes classes could be created for specific dimensions and data types if the automatic calculation of the dimension does not work or a specific data type is requested by the COM server. The new object does support, comparision, sequence protocol, printing and representation. The changed files a test client and script are attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1195096&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-10-23 23:32:41
|
Patches item #1195096, was opened at 2005-05-04 20:19 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1195096&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 Submitted By: Stefan Schukat (sschukat) >Assigned to: Mark Hammond (mhammond) Summary: Native access to SAFEARRAY with wrapper class Initial Comment: The conversion to/from SAFEARRAYs to tuples takes up a lot of time if the SAFEARRAYs are really big. Therefore I created a wrapper class which does not copy any data and just wraps the access to the underlying SAFEARRAY data. In addition to the performance improvements thes classes could be created for specific dimensions and data types if the automatic calculation of the dimension does not work or a specific data type is requested by the COM server. The new object does support, comparision, sequence protocol, printing and representation. The changed files a test client and script are attached. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-10-24 09:32 Message: Logged In: YES user_id=14198 Sorry for the delay here - I'll check this out after I release the next pywin32 build - in the next few days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1195096&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-10 04:20:46
|
Patches item #1195096, was opened at 2005-05-04 20:19 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1195096&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 Submitted By: Stefan Schukat (sschukat) Assigned to: Mark Hammond (mhammond) Summary: Native access to SAFEARRAY with wrapper class Initial Comment: The conversion to/from SAFEARRAYs to tuples takes up a lot of time if the SAFEARRAYs are really big. Therefore I created a wrapper class which does not copy any data and just wraps the access to the underlying SAFEARRAY data. In addition to the performance improvements thes classes could be created for specific dimensions and data types if the automatic calculation of the dimension does not work or a specific data type is requested by the COM server. The new object does support, comparision, sequence protocol, printing and representation. The changed files a test client and script are attached. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-01-10 15:20 Message: Logged In: YES user_id=14198 I like the idea of this, but I'm not that happy with the global used to change the behaviour. My main concern is for an application using one lib that wants SafeArrays, and the other wanting tuples, and no clear answer about who is "correct" I assume that the new SafeArray type will operate exactly like a tuple in every way - but that the "type()" will obviously be different - so that the vast majority of programs will see no change. I'd prefer an approach like I am taking for the "Decimal" objects. Specifically: * create a pythoncom.__future_safearray_ flag - default is False, but ppl can set it to true to get the new behaviour (globally) now. * A few/many builds in the future, we start issuing deprecation warnings whenever SafeArrays are used without this flag being set. * A few/many builds after that the new behaviour becomes the default. Would that work for you? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-10-24 09:32 Message: Logged In: YES user_id=14198 Sorry for the delay here - I'll check this out after I release the next pywin32 build - in the next few days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1195096&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-10 08:53:11
|
Patches item #1195096, was opened at 2005-05-04 12:19 Message generated for change (Comment added) made by sschukat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1195096&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 Submitted By: Stefan Schukat (sschukat) Assigned to: Mark Hammond (mhammond) Summary: Native access to SAFEARRAY with wrapper class Initial Comment: The conversion to/from SAFEARRAYs to tuples takes up a lot of time if the SAFEARRAYs are really big. Therefore I created a wrapper class which does not copy any data and just wraps the access to the underlying SAFEARRAY data. In addition to the performance improvements thes classes could be created for specific dimensions and data types if the automatic calculation of the dimension does not work or a specific data type is requested by the COM server. The new object does support, comparision, sequence protocol, printing and representation. The changed files a test client and script are attached. ---------------------------------------------------------------------- >Comment By: Stefan Schukat (sschukat) Date: 2006-01-10 09:53 Message: Logged In: YES user_id=977439 I already saw that problem and included therefore included pythoncom.SetSafeArrayType(bool) to set the flag programmatically. Your suggestion would lead to the same result. So I have no objections, but as long as the PySafeArrayType does successfully pass the tuple test suite I would give the user the choice. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-01-10 05:20 Message: Logged In: YES user_id=14198 I like the idea of this, but I'm not that happy with the global used to change the behaviour. My main concern is for an application using one lib that wants SafeArrays, and the other wanting tuples, and no clear answer about who is "correct" I assume that the new SafeArray type will operate exactly like a tuple in every way - but that the "type()" will obviously be different - so that the vast majority of programs will see no change. I'd prefer an approach like I am taking for the "Decimal" objects. Specifically: * create a pythoncom.__future_safearray_ flag - default is False, but ppl can set it to true to get the new behaviour (globally) now. * A few/many builds in the future, we start issuing deprecation warnings whenever SafeArrays are used without this flag being set. * A few/many builds after that the new behaviour becomes the default. Would that work for you? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-10-24 01:32 Message: Logged In: YES user_id=14198 Sorry for the delay here - I'll check this out after I release the next pywin32 build - in the next few days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1195096&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-10 10:04:31
|
Patches item #1195096, was opened at 2005-05-04 20:19 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1195096&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 Submitted By: Stefan Schukat (sschukat) Assigned to: Mark Hammond (mhammond) Summary: Native access to SAFEARRAY with wrapper class Initial Comment: The conversion to/from SAFEARRAYs to tuples takes up a lot of time if the SAFEARRAYs are really big. Therefore I created a wrapper class which does not copy any data and just wraps the access to the underlying SAFEARRAY data. In addition to the performance improvements thes classes could be created for specific dimensions and data types if the automatic calculation of the dimension does not work or a specific data type is requested by the COM server. The new object does support, comparision, sequence protocol, printing and representation. The changed files a test client and script are attached. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-01-10 21:04 Message: Logged In: YES user_id=14198 Thanks. Sorry I wasn't more clear - my idea ends up with the same end result, although also provides a transition plan to the New World Order! :) I don't think we do want to give the user a choice, as the user may be using libraries they have no control over, but which have made a different choice - like the "currency" issue, its important there is only one 'correct' thing we return. As mentioned, there is already existing __future_ related code dealing with currencies - if you could adopt your patch to something similar, it reduces any adaptation I need to make to the patch. Cheers ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2006-01-10 19:53 Message: Logged In: YES user_id=977439 I already saw that problem and included therefore included pythoncom.SetSafeArrayType(bool) to set the flag programmatically. Your suggestion would lead to the same result. So I have no objections, but as long as the PySafeArrayType does successfully pass the tuple test suite I would give the user the choice. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-01-10 15:20 Message: Logged In: YES user_id=14198 I like the idea of this, but I'm not that happy with the global used to change the behaviour. My main concern is for an application using one lib that wants SafeArrays, and the other wanting tuples, and no clear answer about who is "correct" I assume that the new SafeArray type will operate exactly like a tuple in every way - but that the "type()" will obviously be different - so that the vast majority of programs will see no change. I'd prefer an approach like I am taking for the "Decimal" objects. Specifically: * create a pythoncom.__future_safearray_ flag - default is False, but ppl can set it to true to get the new behaviour (globally) now. * A few/many builds in the future, we start issuing deprecation warnings whenever SafeArrays are used without this flag being set. * A few/many builds after that the new behaviour becomes the default. Would that work for you? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-10-24 09:32 Message: Logged In: YES user_id=14198 Sorry for the delay here - I'll check this out after I release the next pywin32 build - in the next few days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1195096&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-26 13:30:32
|
Patches item #1195096, was opened at 2005-05-04 12:19 Message generated for change (Comment added) made by sschukat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1195096&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 Submitted By: Stefan Schukat (sschukat) Assigned to: Mark Hammond (mhammond) Summary: Native access to SAFEARRAY with wrapper class Initial Comment: The conversion to/from SAFEARRAYs to tuples takes up a lot of time if the SAFEARRAYs are really big. Therefore I created a wrapper class which does not copy any data and just wraps the access to the underlying SAFEARRAY data. In addition to the performance improvements thes classes could be created for specific dimensions and data types if the automatic calculation of the dimension does not work or a specific data type is requested by the COM server. The new object does support, comparision, sequence protocol, printing and representation. The changed files a test client and script are attached. ---------------------------------------------------------------------- >Comment By: Stefan Schukat (sschukat) Date: 2006-01-26 14:30 Message: Logged In: YES user_id=977439 I attached changed source for the 207 branch, with the suggested __future__ changed. I also added testcode and extended the PyCOMTest server. Stefan ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-01-10 11:04 Message: Logged In: YES user_id=14198 Thanks. Sorry I wasn't more clear - my idea ends up with the same end result, although also provides a transition plan to the New World Order! :) I don't think we do want to give the user a choice, as the user may be using libraries they have no control over, but which have made a different choice - like the "currency" issue, its important there is only one 'correct' thing we return. As mentioned, there is already existing __future_ related code dealing with currencies - if you could adopt your patch to something similar, it reduces any adaptation I need to make to the patch. Cheers ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2006-01-10 09:53 Message: Logged In: YES user_id=977439 I already saw that problem and included therefore included pythoncom.SetSafeArrayType(bool) to set the flag programmatically. Your suggestion would lead to the same result. So I have no objections, but as long as the PySafeArrayType does successfully pass the tuple test suite I would give the user the choice. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-01-10 05:20 Message: Logged In: YES user_id=14198 I like the idea of this, but I'm not that happy with the global used to change the behaviour. My main concern is for an application using one lib that wants SafeArrays, and the other wanting tuples, and no clear answer about who is "correct" I assume that the new SafeArray type will operate exactly like a tuple in every way - but that the "type()" will obviously be different - so that the vast majority of programs will see no change. I'd prefer an approach like I am taking for the "Decimal" objects. Specifically: * create a pythoncom.__future_safearray_ flag - default is False, but ppl can set it to true to get the new behaviour (globally) now. * A few/many builds in the future, we start issuing deprecation warnings whenever SafeArrays are used without this flag being set. * A few/many builds after that the new behaviour becomes the default. Would that work for you? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-10-24 01:32 Message: Logged In: YES user_id=14198 Sorry for the delay here - I'll check this out after I release the next pywin32 build - in the next few days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1195096&group_id=78018 |
