Zooko O'Whielacronx <zo...@zooko.com> added the comment: There seems to be some mistake, re #msg134219 and #msg134255. The current version of may patch *does* avoid the cost of a subprocess in the common case. I described this new strategy in #msg73744 and as far as I know it satisfies all of MAL's earlier objection about that.
To recap, this code here: http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/__init__.py?annotate=blame&rev=5033#L36 does the following strategy: 1. Parse the /etc/lsb-release file. /etc/lsb-release is not part of the de jure standard, but it is a de facto standard that is available on many distributions. Parsing it is fast and gives the right answer on many distributions. 2. If that didn't work (which can happen on some distributions, including common ones when a certain optional "lsb base" package isn't installed), then invoke the current platform.dist() code. This is a lot of code, its code has to be changed before it can recognize any new distribution or a change in a distribution, and it gives answers on Ubuntu and Arch Linux which users say are the wrong answer, but it is fast and it gives the answer users want in most cases. 3. If that didn't work (which presumably only happens on distributions that the authors of platform.dist() didn't know about or didn't bother to support), then invoke the de jure standard executable "lsb_release". This works on any LSB-compliant system, but it costs a subprocess. 4. If that didn't work, check for /etc/arch-release to signal Arch Linux. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1322> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
