This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author leycec
Recipients andymaier, benjamin.peterson, berker.peksag, bgomes, christian.heimes, doko, draghuram, eric.araujo, georg.brandl, lemburg, leycec, nir0s, pavel.vinogradov, petr.viktorin, pola, python-dev, sapetnioc, vajrasky, xnox, zooko
Date 2016-04-13.07:35:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1460532951.71.0.823907126239.issue1322@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2016-04-13 07:35:52leycecsetrecipients: + leycec, lemburg, georg.brandl, doko, zooko, draghuram, christian.heimes, sapetnioc, benjamin.peterson, pavel.vinogradov, bgomes, eric.araujo, petr.viktorin, python-dev, pola, berker.peksag, xnox, vajrasky, andymaier, nir0s
2016-04-13 07:35:51leycecsetmessageid: <1460532951.71.0.823907126239.issue1322@psf.upfronthosting.co.za>
2016-04-13 07:35:51leyceclinkissue1322 messages
2016-04-13 07:35:51leyceccreate