On Oct 13, 2014, at 14:40, Victor Stinner firstname.lastname@example.org wrote:
2014-09-24 21:21 GMT+02:00 Stefano Borini email@example.com:
I am wondering if it would be possible to include psutil (https://pypi.python.org/pypi/psutil ) in the standard library, and if not, what would be needed.
The problem is that Python only releases a new major version every 18 months (or something like that), so adding a single new function will take so much time.
Supporting a new platform, architecture, major version of an OS, etc. may also need to wait a new Python major release.
Operating systems are evolving quite fast. For example, there is the new architecture AArch64, containers are more and more popular, systemd can also be used to provide features similar to psutil and it supports containers (running systemd, it even supports recursive containers....). Network becomes more virtual with Software Defined Networks (SDN, NFV, etc.). The Linux kernel is also extended at each release. Example of "recent" addition: /proc/pid/fdinfo/ directory. Does psutil provide NUMA information? NUMA also becomes more information nowadays for performances.
The psutil also still evolves. For example, I see that the version 2.1 released at April, 2014 adds "netstat-like functionalities". The version 2.0 was only released one month before (March, 2014).
The API of psutil changed a lot between 1.x and 2.0. The version 2.0 was only released a few months ago. Is it enough to consider that the API is now stable enough (was enough tested)? Giampaolo (author of the module) doesn't look to be confident in its own API ;-) He wrote "I still want to work on a couple of new features first (...) and be 100% sure that I'm happy with the API as it is right now".
Maybe I'm wrong and the psutil is stable and can be "frozen" in the standard library. Maybe it's possible to extract a subpart of the psutil to keep the most stable part?
I'm not strongly opposed to the integration of the psutil module into the stdlib.
Is it hard to install the psutil module today? I see wheel packages and .exe installers for Windows. They are Linux packages (Debian, Ubuntu, Fedora, ArchLinux, etc.)
This might be a good idea.
It seems to me that there are two common uses for psutil.
Some people want just a little bit more than Python makes available, and they want it in a cross-platform (at least gnu vs. bsd vs. sysv, if not unix vs. windows) way. That doesn't change that much over time, and adding that much from psutil to the stdlib might make sense.
Other people want all kinds of detailed process information, in a platform-specific way, without having to grub through low-level APIs. That changes frequently, and for those people, pip install psutil should probably remain the right answer.
(Of course there are also people who use psutil to do the exact same things subprocess and os can already do better; for those people, the answer is to stop doing that...)
I guess the real question is, what are the use cases for the "stable core"? Once we know that, we can identify whether it's stable enough and simple enough to extract.