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 larry
Recipients Arfrever, Ramchandra Apte, amaury.forgeotdarc, barry, benjamin.peterson, djc, dmalcolm, doko, eric.araujo, ezio.melotti, foom, gagern, georg.brandl, jwilk, larry, lemburg, loewis, petri.lehtinen, pitrou, python-dev, r.david.murray, rosslagerwall, sandro.tosi, vstinner
Date 2011-08-21.12:05:44
SpamBayes Score 7.187584e-12
Marked as misclassified No
Message-id <1313928345.81.0.566792938986.issue12326@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2011-08-21 12:05:45larrysetrecipients: + larry, lemburg, loewis, barry, georg.brandl, doko, amaury.forgeotdarc, gagern, foom, pitrou, vstinner, benjamin.peterson, jwilk, djc, ezio.melotti, eric.araujo, Arfrever, r.david.murray, dmalcolm, sandro.tosi, rosslagerwall, python-dev, petri.lehtinen, Ramchandra Apte
2011-08-21 12:05:45larrysetmessageid: <1313928345.81.0.566792938986.issue12326@psf.upfronthosting.co.za>
2011-08-21 12:05:45larrylinkissue12326 messages
2011-08-21 12:05:44larrycreate