Make cpu_times() and memory_info() return a named tuple instead of a plain tuple

[giampaolo]

From g.rodola on June 22, 2010 18:54:59

Specifically I'm talking about Process.get_cpu_times() and Process.get_memory_info() which return plain tuples as such:

>>> psutil.Process(os.getpid()).get_cpu_times()
(0.02, 0.0)
>>> psutil.Process(os.getpid()).get_memory_info()
(4526080, 6561792)

Turning them into named tuples would mean adding the ability to 
access fields by name instead of just position index and also have a 
more meaningful repr, maintaining full retro compatibility with plain tuples:

>>> mem = psutil.Process(os.getpid()).get_memory_info()
>>> mem
meminfo(rss=4526080, vms=6561792)
>>> mem[0]
4526080
>>> mem.rss
4526080

The same thing should be done for psutil.cpu_times() which currently 
uses psutil.CPUTimes class, which emulates a namedtuple behavior and which should just go away.

collections.namedtuple has been introduced only in python 2.6: 
http://docs.python.org/dev/library/collections.html#namedtuple-factory-function-for-tuples-with-named-fields
 Since we support also python 2.4 and 2.5 we can use this recipe 
which implements a namedtuple in pure python: 
http://code.activestate.com/recipes/500261-named-tuples/ This can go 
into a new psutil/utils.py module which we can possibly use for something else in future.

Original issue: http://code.google.com/p/psutil/issues/detail?id=98

[giampaolo]

From jlo...@gmail.com on June 22, 2010 10:11:16

I like this idea, and it makes sense to me, however I might recommend 
that we avoid the name "utils" for a module, as psutil.utils is a bit awkward/confusing at first glance - just a thought :-)

If we're not going to add anything else to such a module right now, 
we could just only support named tuples on 2.6 and higher, and 
otherwise fall back to a standard tuple. This is more of a "nice to 
have" feature than a critical one anyway, and > 100 lines of code just to add named tuples to the older Python versions.

[giampaolo]

From g.rodola on June 22, 2010 10:36:18

I agree it is more of a "nice to have" feature but changing types 
between python versions introduces a level of incompatibility and discrepancy.
Also, deciding whether use a tuple or a named tuple in the code would be somewhat twisted.
If you're worried about the recipe code I think we can manage to shorten it up a little.

> I might recommend that we avoid the name "utils" for a module, as psutil.
> utils is a bit awkward/confusing at first glance - just a thought :-)

Agreed. Ideas? What about compatibility.py?

[giampaolo]

From jlo...@gmail.com on June 22, 2010 11:07:29

I would vote for "compat.py", it's shorter and it's a standard abbreviation for compatibility related libs or code.

[giampaolo]

From g.rodola on June 22, 2010 12:42:52

Labels: Milestone-0.2.0

[giampaolo]

From g.rodola on June 23, 2010 09:52:51

Thinking back, psutil.cpu_times() should keep returning a CPUTimes 
object: the position of the values returned as a namedtuple object 
varies depending on the platform so that psutil.cpu_times()[4] on Linux, for example, has a different meaning on Windows.

CPUTimes didn't have this problem since it doesn't implement position index.

[giampaolo]

From g.rodola on July 02, 2010 12:42:00

Implemented on Linux ( r575 ), Windows ( r576 ), BSD and OSX ( r581 ).
CPUInfo changes reverted as r579 and r580 .

Status: Fixed
Labels: -Progress-0in4 Progress-4in4

[giampaolo]

From g.rodola on March 02, 2013 03:53:29

Updated csets after the SVN -> Mercurial migration: r575 == revision f04e3745bf81 r579 == revision fd053962d42e