#65 Native access to SAFEARRAY with wrapper class

[Stefan Schukat]

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.

[Stefan Schukat]

Files changed to source of 204

[Mark Hammond]

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.

[Mark Hammond]

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?

[Stefan Schukat]

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.

[Mark Hammond]

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

[Stefan Schukat]

Files changed to source of 207

[Stefan Schukat]

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

[Mark Hammond]

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)

[Mark Hammond]

original changes in .patch format

[Marco Rossi]

Any progress on this issue?