New submission from Jason R. Coombs <jar...@jaraco.com>:
or: Unable to implement 'uname' on Python due to recursive call or: platform.uname() should avoid calling `uname` in a subprocess In [this issue](https://github.com/jaraco/cmdix/issues/1), I stumbled across a strange and somewhat unintuitive behavior. This project attempts to supply a `uname` executable implemented in Python, so that such functionality could be exposed on any platform including Windows. What I found, however, was that because the stdlib `platform` module actually invokes `sh -c uname -p` during most any call of the module (https://github.com/python/cpython/blob/9db56fb8faaa3cd66e7fe82740a4ae4d786bb27f/Lib/platform.py#L836), attempting to use that functionality on a system where `uname` is implemented by Python (and on the path), will probably fail after a long delay due to infinite recursion. Moreover, the _only_ call that's currently invoking `uname` in a subprocess is the `processor` resolution, which I suspect is rarely used, in part because the results from it are inconsistent and not particularly useful. For example, on Windows, you get a detailed description from the hardware: 'Intel64 Family 6 Model 142 Stepping 9, GenuineIntel' On macOS, you get just 'i386'. And on Linux, I see 'x86_64' or sometimes just '' (in docker). To make matters even worse, this `uname -p` call happens unconditionally on non-Windows systems for nearly any call in platform. As a result, it's impossible to suppress the invocation of `uname`, especially when functionality like `pkg_resources` and its environment markers is invoked early. I suggest instead the platform module should (a) resolve processor information in a more uniform manner and (b) not ever call uname, maybe [with something like this](https://github.com/jaraco/cmdix/blob/d61e6d3b40032a25feff0a9fb2a79afaa7dcd4e0/cmdix/command/uname.py#L53-L77). At the very least, the `uname` call should be late-bound so that it's not invoked unconditionally for rarely-used information. After some period for comment, I'll draft an implementation. ---------- messages: 335220 nosy: jaraco priority: normal severity: normal status: open title: Better platform.processor support _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35967> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
