Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#65 Native access to SAFEARRAY with wrapper class

open
Mark Hammond
None
5
2005-10-23
2005-05-04
Stefan Schukat
No

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.

Discussion

  • Stefan Schukat
    Stefan Schukat
    2005-05-04

    Files changed to source of 204

     
    Attachments
  • Mark Hammond
    Mark Hammond
    2005-10-23

    • assigned_to: nobody --> mhammond
     
  • Mark Hammond
    Mark Hammond
    2005-10-23

    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
    Mark Hammond
    2006-01-10

    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
    Stefan Schukat
    2006-01-10

    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
    Mark Hammond
    2006-01-10

    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
    Stefan Schukat
    2006-01-26

    Files changed to source of 207

     
  • Stefan Schukat
    Stefan Schukat
    2006-01-26

    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
    Mark Hammond
    2006-08-30

    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
    Mark Hammond
    2006-08-30

    original changes in .patch format

     
    Attachments