pcp
[Top] [All Lists]

Re: fetchgroups api - python bindings

To: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Subject: Re: fetchgroups api - python bindings
From: Marko Myllynen <myllynen@xxxxxxxxxx>
Date: Wed, 9 Dec 2015 13:03:57 +0200
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <y0m4mft10vf.fsf@xxxxxxxx>
Organization: Red Hat
References: <20151206204742.GC22561@xxxxxxxxxx> <5666E4F7.4070005@xxxxxxxxxx> <y0m4mft10vf.fsf@xxxxxxxx>
Reply-to: myllynen@xxxxxxxxxx
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
Hi,

On 2015-12-08 16:16, Frank Ch. Eigler wrote:
> 
>>> v = pmfg.extend_item("hinv.ncpu", c_api.PM_TYPE_U32)
>>> vv = pmfg.extend_indom("kernel.all.load", c_api.PM_TYPE_FLOAT)
>>
>> - I mentioned about this earlier relating to the C API but I think it's
>> worth checking again with the Python side: has the type argument really
>> be mandatory here? If the user don't pass it, it'd require two lines to
>> figure it out in the Python layer on the user's behalf and the user can
>> later on do type(v()) or str(v()) or such as needed. [...]
> 
> You've got a pretty good case with python, since it's so dynamically
> typed already.  OK, will accept None.
> 
>> - Regardless of the above, perhaps it might be better to define
>> extend_item(self, metric=None, mtype=None, scale=None, instance=None)
>> instead of
>> extend_item(self, metric=None, mtype=None, instance=None, scale=None)
> 
> You're right.

thanks for the updates, I checked the latest code in git and it looks
all good now. (There are few things marked with XXX on C side but I
don't see them being show-stoppers for merging.)

Cheers,

-- 
Marko Myllynen

<Prev in Thread] Current Thread [Next in Thread>