Jason R. Coombs <jar...@jaraco.com> added the comment:
> you added a late binding optimization for the whole uname return tuple to save the effort of ... shell access. It wasn't to save the effort and it wasn't an optimization. There was a fundamental race condition where it became impossible to implement a `uname` command using Python because `platform.system()` (or anything else that delegated to `platform.uname()`) would unconditionally shell out to `uname`, and this would happen early, before a library could intercept the behavior. See issue35967 for more details on the motivation and challenges. > I think this would have been better implemented... This idea is interesting, but I believe it also falls prey to the same race condition if any code calls `platform.uname()` before a Python-based uname implementation has a chance to monkeypatch the behavior. May I suggest that you either revive the conversation in issue35967 or open a new ticket to discuss improving the implementation so that the details aren't lost in this ticket, which was specifically about compatibility issues? > I don't think that deprecating standard tuple access is an option for the uname() return value, since it's documented to be a tuple. I'll address this concern in the ticket I opened about the deprecation. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue40570> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
