[issue12795] Remove the major version from sys.platform

Marc-Andre Lemburg report at bugs.python.org
Mon Aug 22 11:20:16 CEST 2011


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> FreeBSD or OpenBSD release major version frequently, something like one 
> per year, or one per two years. FreeBSD and OpenBSD developers knows 
> that for years, and Python programs use sys.platform.startswith() for 
> these OSes.
> 
> For Linux, it's different. Linux 2.0 was released in 1997 and 3.0 in 
> 2011: it took 14 years to change the major version. It don't think that 
> any program working on Linux was prepared for this change: see #12326 
> history to have an idea on the problem. It looks like 
> sys.platform=='linux3' breaks most programs testing sys.platform 
> (including Python itself because of Lib/plat-linux2/ directory).
> 
> If you want the OS name, use platform.system() or os.uname()[0].
> 
> If you want the OS version, use platform.release(). If you want the OS 
> version as a tuple, hum... see the issue #12794.

Victor, you are constantly mixing build time information with
runtime information. Those are two different types of information
and we should regard them as such.

sys.platform refers to build time information, so the platform
module won't help.

The version of the build platform is important to know, but
adding it to sys.platform is not necessarily the right
thing to do, since adding just the major version is often
not enough (see Mac OS X) and can sometimes lead to breakage
due to frequent new releases of OSes (see FreeBSD).

Given that the various OSes use different schemes for versioning
and backwards compatibility, a single string cannot possibly
cover all aspects.

Separating the information into OS name and version is a much
more future proof approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12795>
_______________________________________


More information about the Python-bugs-list mailing list