Marc-Andre Lemburg <m...@egenix.com> added the comment: Moved the discussion here from issue12326:
>> [Larry Hastings] >> >> If we're changing "linux2" / "linux3" to just "linux", we should be >> >> consistent and do it for everybody. I propose sys.platform under 3.3 >> >> should contain things like "linux", "freebsd", "openbsd", "darwin", >> >> and "windows". > [Martin v. Löwis] > > Definitely not. The reasoning that applies to Linux doesn't necessarily > > apply to the other systems. My understanding that it definitely does not > > apply to HP-UX, where major version number changes really indicate major > > changes (unlike in Linux). Actually, with that reasoning we would need to reintroduce the version for Mac OS, and even go a step further and add the minor version number as well, since since major changes have happened on Mac OS with every single minor release for the last couple of years. IMO, a better approach is to split the information in two parts: * sys.platform, which only specifies the platform name on which Python was built (uname -s) * sys.platform_build_version, which provides the full platform version (uname -r; either as string or as tuple or both - that would have to be hashed out) It is obvious that the version number in sys.platform often doesn't really get used (see Victor's example). In such cases, having access to just the build platform name is better. In other cases, where you do need to know the version (e.g. on Mac OS X), you can then easily get if from the new attribute, and including the minor and even patch level release version details (e.g. to determine whether Python was compiled with a Windows specific service pack in place or not). ---------- nosy: +lemburg resolution: invalid -> status: closed -> open _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12795> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
