leycec added the comment: Deprecating platform.linux_distribution() while retaining platform.win32_ver() and platform.mac_ver() is non-orthogonal, unjustifiable, and (arguably) discriminatory.
Platform version detection is no more a moving target under Linux than under Windows or OS X -- possibly less so, given the numerous significant revisions to platform.win32_ver() implementations over the dreary years. If Linux is arbitrarily unentitled to platform-specific lookup functions, then other platforms deserve the same. Unlike both Windows and OS X, the overwhelming majority of Linux distributions provide a trivially parsable plaintext file publishing high-level platform metadata in "="-delimited shell variable assignment format: the systemd-mandated and freedesktop.org-maintained "/etc/os-release" file. Under edge-case Linux distributions ideologically rejecting this standard (e.g., Gentoo Linux), a subset of the named tuple returned by platform.uname() is trivially returnable. Do not parse multiple possibly conflicting files, commands, or standards. Doing so is neither necessary nor desirable. If "/etc/os-release" exists, parse that; else, fallback to platform.uname(). Done. Fait accompli. Quite simple. No moving target exists. A robust platform.linux_distribution() implementation adhering to this scheme is implementable in less than 50 lines of code -- possibly less than 20, assuming aggressive cleverness. How? If "/etc/os-release" exists, this file is guaranteed to be POSIX shell-compatible and hence Pythonically parsable via the stdlib shlex.shlex() function. (In brief: iteratively search for tokens containing "=", split these tokens on "=", ignore irrelevant variable names, and retain the remainder. That's it.) The fallback alternative is even briefer. Removing core functionality invites third-party API explosion. This is the height of irresponsibility. Brace for heavyweight dependencies, end-user confusion, multiple competing non-standards, and poorly selected PyPi names conflicting with the long-standing GNU toolchain. (See nir0s' "ld", also referred to as "What was nir0s thinking?") None of these are good things. Given the unremarkable simplicity of implementing this function correctly, this cul-de-sac of Cthulhian insanity needn't have happened in the first place. It did. Now we languish. ---------- nosy: +leycec _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1322> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
