Steve Dower <steve.do...@python.org> added the comment:

> 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.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue35896>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to