[python-win32] win32com array handling bug?

[Mark Hammond]

sorry for the delay:

> From: python-win32-bounces at python.org
> [mailto:python-win32-bounces at python.org]On Behalf Of Jason Ferrara
> Sent: Saturday, 14 July 2007 1:51 AM
> To: Mark Hammond
> Cc: python-win32 at python.org
> Subject: Re: [python-win32] win32com array handling bug?

...

> I don't think that a tuple of buffers, as you describe below, is
> really the right thing. For that to work either you have to reverse
> the dimension order of the array, or the buffers have to
> contain data
> that originally wasn't contiguous (the buffers hold columns instead
> of rows). Neither seems particularly useful.

I'm a little confused by that.  If I create an array with dims [8,5], I end
up with 8 rows and 5 columns.  I don't see why I could return 8 tuples of
strings, each with length 5.  Each tuple would hold what was initially
contiguous memory.  Joining these strings together would give an exact
representation of the original buffer.

3d arrays might be tricker - my brain has been exploding with just 2d
recently :)

But:

> Would it make sense to return an object thats a buffer that
> holds the
> full array data, but also has some additional attribute that
> contains
> the original array dimensions? For my particular case that would be
> the idea, since I want to feed the data into PIL.Image.frombuffer,
> which takes a buffer plus a size tuple. But I'm not sure what the
> best choice would be for general use.

I can buy that argument.  We are already special-casing UI1, so returning a
"flat" result would seem to make sense.  If the 2d array is large, and
python only needs the data to pass it on somewhere else, there would be
significant performance benefits.  If the initial dimensions were available,
it would still be quite simple for someone to slice the data back up so they
could treat it as an array.

However, I'm a little reluctant to do apply your patch until we do have an
object that can also return the dimensions - otherwise we end up with it
being 1/2 fixed and another few years before it is really "fixed" for all
users.  I've put your patch and the start of some test code at
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1709340&group_i
d=78018 (thanks to Kevin for starting that) and I'd welcome contributions
that allow us to return a new "buffer-like" object that can also records the
dimensions of the array.

Cheers,

Mark