Jason R. Coombs <jar...@jaraco.com> added the comment:
> the output of platform.uname() needs to stay compatible to what the function > returned prior Do we really wish to retain the output for this unreliable interface, especially when it is not standardized and is returning improper information? Is it valuable for `platform.processor()` to return "i386" (a 34-year-old processor) for my 2017 Macbook Pro? Does maintaining compatibility for `platform.uname()` also imply that `platform.processor()` needs to return `platform.uname().processor`, or could the interface on the latter change, to provide a more useful value, while retaining the behavior of `platform.uname()`? My instinct is it's impractical to attempt to maintain all of these forks of "uname -p", especially when the result is a largely unpredictable value, so I'm considering the only other viable option I can conceive now: - retain the subprocess call to "uname", but bind it late, as a functools.cached_property, such that "uname -p" is only ever called when the processor property is requested. This approach would also require overriding __iter__ and __getitem__ to retain the namedtuple interface while having that element resolved late. I was also considering this: instead of invoking "uname" anywhere on the path, invoke it from an explicit whitelist of paths, such as /bin and /usr/bin, so that it's never self-referential. Unfortunately, that wouldn't work if a Python-based implementation were put on one of those paths, so it would be brittle at best. Marc-Andre, I'd love your feedback in light of these challenges. ---------- _______________________________________ 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
