Larry Hastings <la...@hastings.org> added the comment: So what about doing the same for FreeBSD, SunOS, and Windows? The conversation about this point sort of trailed off. But, dammit, a foolish consistency is the hobgoblin of my small mind.
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". I further propose we add a "sys.platform_major_version" which would contain the OS major version number (as an integer!). That'd be 3 for Linux 3.0, 8 for FreeBSD 8, 32 for Win32, and so on. That'd let users easily reconstitute the old value of "sys.platform". (Except on Windows. But I am strangely averse to setting sys.platform to "win" on Windows.) Of course, we should determine this value at runtime rather than build time on platforms where the number could change at runtime. (A counter-example: it need not be late-binding for "windows" 32 vs 64.) With that addition, we can now address plat-freebsd<x>.: * Move the all existing plat-freebsd<x>/IN.py to plat-freebsd/IN<x>.py * Write a new plat-freebsd/IN.py that uses sys.platform_version to read in the correct IN<x>.py. * Alter plat-freebsd/regen to generate IN<x>.py I suspect plat-freebsd<x> should have used the run-time OS major version all along, so this would be an improvement! And since FreeBSD is the only OS with more than one plat-* entry, the plat-* problem is solved. I'm happy to open a new issue discussing this if that's the right thing to do. ---------- nosy: +larry _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12326> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
