[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v6 09/11] iotests: change qmp_log filters to exp

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-devel] [PATCH v6 09/11] iotests: change qmp_log filters to expect QMP objects only
Date: Mon, 24 Dec 2018 08:26:30 +0000

21.12.2018 23:13, John Snow wrote:
> 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.

hmm, yes, I was wrong. Ok, than I'm fine with your code. Take my r-b.

>> 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 <address@hidden>
>> 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

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]