[pywin32-bugs] [ pywin32-Patches-1195096 ] Native access to SAFEARRAY with wrapper class

[SourceForge.net <no...@so...>]

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-08-30 21:53

Message:
Logged In: YES 
user_id=14198

I ran out of time for now - but here is a patch against
current CVS (with no changes by me - just the original
merged against 207)

Running win32com tests generated:
lib\site-packages\win32com\client\dynamic.py:172:
FutureWarning: SAFEARRAY objects will soon be changed so a
pythoncom.SAFEARRAY instance is used.
 (set pythoncom.__future_safearray__ to get these objects now.)
  return
self._get_good_object_(self._oleobj_.Invoke(*allArgs),self._olerepr_.defaultDispatchName,None)


----------------------------------------------------------------------

Comment By: Stefan Schukat (sschukat)
Date: 2006-01-27 00: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 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