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 steve.dower
Recipients jcrmatos, paul.moore, pmpp, steve.dower, tim.golden, zach.ware
Date 2019-02-05.19:17:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1549394279.02.0.225528202142.issue35896@roundup.psfhosted.org>
In-reply-to
Content
> sys.platform is defined by code path taken while compiling. it is hardcoded and really represents the os abi used of a *supported* platform

Correct, though the examples I'd give are Win32 vs. WinRT vs. Cygwin, which are fundamentally different API surfaces for interacting with the operating system.

sys.platform is win32 whenever Python is built against the Win32 API. sysconfig.get_platform is win32 when packages need to be built for 32-bit Windows. It's unfortunate that they were chosen to be the same, but that's long in the past, and I don't think the confusion is worth the confusion that would occur if it changed.

os.name is also odd, and honestly I'd rather it just went away completely. I'd like the module to be called "posix" everywhere, since that's the API it exposes (it's an emulation layer on non-POSIX platforms), and checks should use sys.platform. Or at worst, "_os" instead of having an importable "nt" module. But for better or worse, that's how Python is designed, and until there's a serious project to redesign aspects at this level we aren't going to see any change.
History
Date User Action Args
2019-02-05 19:18:00steve.dowersetrecipients: + steve.dower, paul.moore, tim.golden, pmpp, zach.ware, jcrmatos
2019-02-05 19:17:59steve.dowersetmessageid: <1549394279.02.0.225528202142.issue35896@roundup.psfhosted.org>
2019-02-05 19:17:59steve.dowerlinkissue35896 messages
2019-02-05 19:17:58steve.dowercreate