On 14 October 2014 08:49, Andrew Barnert email@example.com wrote:
On Oct 13, 2014, at 14:40, Victor Stinner firstname.lastname@example.org wrote:
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.
Right, "use case driven design" is the way to go. In particular, some of the key drivers for standard libraries additions in recent times have been:
1. Adding a module because we want to use it in the standard library (enum) 2. Adding a module because it smooths the learning curve for folks learning programming and other computing concepts (ipaddress, statistics) 3. Adding a module as part of a broader Python ecosystem interoperability effort (asyncio) 4. Adding a module because it is closely coupled to internal interpreter details (tracemalloc)
A "minimal psutil" strikes me as something that could be useful for learning about computers by way of learning to program in Python - listing processes, users, network connections, memory usage, etc. Having that kind of basic capability in the standard library could be quite beneficial to a broad audience.
The more sophisticated capabilities in psutil around resource limiting, and providing alternative interfaces to standard library functionality would likely make less sense in a standard library module (especially as these are the ones more likely to evolve over time).