Re: [Qemu-devel] [PATCH v6 09/11] iotests: change qmp_log filters to expect QMP objects only

[John Snow <jsnow@redhat.com>]

On 12/21/18 7:41 AM, Vladimir Sementsov-Ogievskiy wrote:
> Hmm. This made me check, is enumerate applicable to dicts,
> and, yes it is.
> 

enumerate on dicts gives you a numerical index paired with the key,
so... k is the numerical index and v is the key.

> so, it may be as easy as
> 
>      for k, v in enumerate(qmsg):
>          if isinstance(v, list) or isinstance(v, dict):
>              qmsg[k] = filter_qmp(v, filter_fn)

                    ^ this will break if qmsg was a dict.

>          else:
>              qmsg[k] = filter_fn(k, v)
> 
> with this:
> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> 
> 
> But does it what you want?
> So, for lists of strings, filter_fn will get pair of index in array
> and value?
> On the other hand, we can adjust the behavior as we want when we introduce
> such filters.

I'm not sure what I want...

Named index is the best, but isn't always available because like you
say, the object we are passed is not always a dictionary. We could
theoretically have a list of lists somewhere. What key would I pass
then? It's meaningless.

I could change qmp_filter to pass the k,v to the filter when it finds
the "last dictionary," i.e. if it recursively finds no more dictionaries
underneath, it passes the value along regardless of whatever it finds.
This is a bit more complex because I think I'd need a co-mutual
recursive function to "travel" each value and report if there are
further dictionaries down below.

Or, I could just leave the filter as-is where it only ever gets one,
non-dict/non-list item and receives a key. Sometimes the key will now be
a numerical index which is likely not useful...

I might stage this as-is for now. Let's revisit it before 4.0 rc0.

--js