Nothing is failing yet.  But it could in future versions of MQ if they
decide to add an array to the md parameters.

The current pack allows for the handling of arrays:

    def pack(self):
        """ pack()
        
        Pack the attributes into a 'C' structure to be passed to MQI
        calls. The pack order is as defined to the MQOpts
        ctor. Returns the structure as a string buffer"""
        
        # Build tuple for struct.pack() argument. Start with format
        # string. 
        args = [self.__format]
        # Now add the current attribute values to the tuple
        for i in self.__list:
            v = getattr(self, i[0])
            # Flatten attribs that are arrays
            if type(v) is types.ListType:
                for x in v:
                    args.append(x)
            else:
                args.append(v)
        return apply(struct.pack, args)


The current unpack does not:

    def unpack(self, buff):
        """unpack(buff)

        Unpack a 'C' structure 'buff' into self."""
        
        # Unpack returns a tuple of the unpacked data, in the same
        # order (I hope!) as in the ctor's list arg.
        r = struct.unpack(self.__format, buff)
        x = 0
        for i in self.__list:
            setattr(self, i[0], r[x])
            x = x + 1

Currently the only things that are unpacked are of class md and pmo
        mDesc.unpack(rv[0])
        putOpts.unpack(rv[1])
 in various locations.

An example of a class that does call pack and does have arrays as
arguments is cd.

        if "6.0" in pymqe.__mqlevels__:
            opts += [['HdrCompList', [0L, -1L], '2' + MQLONG_TYPE],
                     ['MsgCompList', [0] + 15 * [-1L], '16' +
MQLONG_TYPE],
                     ['CLWLChannelRank', 0L, MQLONG_TYPE],
                     ['CLWLChannelPriority', 0L, MQLONG_TYPE],
                     ['CLWLChannelWeight', 50L, MQLONG_TYPE],
                     ['ChannelMonitoring', 0L, MQLONG_TYPE],
                     ['ChannelStatistics', 0L, MQLONG_TYPE]]

HdrCompList and MsgCompList are examples of options that are arrays.

If in the future, if MQ decides to add an option that is an array in md
or pmo, and the options are added to pymqi.py, it will break because the
current unpack does not unpack arrays.

Here is a way you can test if you would like:

Since cd has arrays for arguments, it can be used for testing.
In the connectWithOptions function after the line ocd = cd() add the
following:

print 'cd structure before packing and unpacking'
print ocd
print 'cd structure after packing and unpacking'
print ocd

Then run some test code that calls connectWithOptions or call
connectTCPClient that calls connectWithOptions.

In the output, look at HdrCompList and MsgCompList before and after.
Notice before they are arrays and after they are not.  You can see in
the after that the array values are spread to the following arguments
which totally messes up the rest of the arguments.

Next, make the changes I suggested to the unpack to unflatten the arrays
and rerun your test and you will see the before and after printouts of
the cd structure are the same.

    def unpack(self, buff):
        """unpack(buff)

        Unpack a 'C' structure 'buff' into self."""
        
        # Unpack returns a tuple of the unpacked data, in the same
        # order (I hope!) as in the ctor's list arg.
        r = struct.unpack(self.__format, buff)
        x = 0
        for i in self.__list:
           v = getattr(self, i[0])
           # Unflatten attribs that are arrays.
           if type(v) is types.ListType:
              r_list = []
              for jj in range(len(v)):
                 r_list.append(r[x])
                 x += 1
              setattr(self, i[0], r_list)
           else:
              setattr(self, i[0], r[x])
              x += 1

Basically, the bottom line is this, the unpack is supposed to undo what
the pack does.  The current pack handles arrays and the current unpack
does not.  This works because currently, nothing that is unpacked has
arrays.  This may not be the case in later versions of MQ.  The new
unpack code works exactly the same for data that does not have arrays as
the current unpack.  There is no reason not to future proof the unpack
as I suggested.

Brent


On Fri, 2010-02-26 at 08:12 +0000, Dariusz Suchojad wrote:
> Hm, I'm sorry, I have somehow missed "if type(v) is types.ListType:"
> line in the your code - still, can you send some sample failing code?
> Thanks again.
>