> 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.