Hi Stan,
----- Original Message -----
> Looks really nice Nathan. Yes I think that is the place for pmsubsys.pl
> as well as it is shared by both. I think pmsubsys.py is pretty much
> okay so maybe that and the corresponding changes for pmcollectl.py could
> be pushed upstream while I tweak on pmatop a bit more.
>
> I am thinking that there is little point in returning status in
> pmapi.py. All exceptions are raised so it is not needed. The gotcha
Ah, that would be good. Might help with some of the pylint warnings too,
where we end up having assignments to never-used-again variables, which are
a result of these multiple-returned-values (IIRC).
> is that some methods like pmExtractValue are now doing:
> return status, outAtom
> would need to be changed to simply
> return outAtom
*nod*.
Now would be a good time to make such changes I think, given other churn
that's underway in the module/package interface.
> I was also speculating if it would be handy for pmExtractValue to return
> multiple values which pmFetch, pmLookupName, pmLookupDesc already do.
Hmmm, not sure. It might complicate things a fair bit because we would
then need to pass in multiple in/out types, formats, etc, and deal with
multiple status codes in the results.
With the other three you list above, these map to over-the-wire protocol
calls too, so batching em up makes more sense (although pmLookupDesc does
not actually allow multiple descs at once - IMO it should have and might
have to one day if that's ever shown to be a problem). pmExtractValue is
a simple (local, in-memory) data format converter, so its less clear if
there's value from doing batching within it. Unless there's a particular
compelling reason/advantage you have in mind, I'd lean toward leaving it
as-is on that one.
cheers.
--
Nathan
|