search

end18 / psutil

Automatically exported from code.google.com/p/psutil
Other
0 stars 0 forks source link

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

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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 reported on code.google.com by g.rodola on 22 Jun 2010 at 4:54

GoogleCodeExporter commented 9 years ago 
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.

Original comment by jlo...@gmail.com on 22 Jun 2010 at 5:11

GoogleCodeExporter commented 9 years ago 
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?

Original comment by g.rodola on 22 Jun 2010 at 5:36

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

Original comment by jlo...@gmail.com on 22 Jun 2010 at 6:07

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 22 Jun 2010 at 7:42

GoogleCodeExporter commented 9 years ago 
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.

Original comment by g.rodola on 23 Jun 2010 at 4:52

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

Original comment by g.rodola on 2 Jul 2010 at 7:42

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Updated csets after the SVN -> Mercurial migration:
r575 == revision f04e3745bf81
r579 == revision fd053962d42e

Original comment by g.rodola on 2 Mar 2013 at 11:53