New submission from Michael Felt <[email protected]>:
Back in 2012 (issue12326 and issue12795), and just recently (issue36588)
sys.platform has been modified (and documented) to not return the platform
version.
Additionally, the recommendation is to use the form
sys.platform.startswith(<platform>) - to continue to be backwards compatible.
IMHO - looking forward - Python3.8 and later - we should not be using the
recommendation for 'backwards-compatibility' in our code (so this PR will not
be considered for back-porting) - in our stdlib, tests, and - should it occur -
in "core" code. We should be testing for equality.
Further, imho, the change should not be sys.platform == <platform> but should
be platform.system() == <Platform>, or platform.system() in ('AIX', 'Darwin',
'Linux') -- and adjust the list so that the most frequently used platform is
tested first (e.g., performance-wise ('Linux', 'Darwin', 'AIX') would better
reflect platform importance.
OR - should the change just continue to use sys.platform - even though this is
a build-time value, not a run-time value.
I propose to do this in separate PR - one for each platform of AIX, Darwin and
Linux.
(I would also add Windows, but that would be to replace the equivalence of
sys.platform == 'win32' with platform.system() == 'Windows', and perhaps,
os.name == 'nt' with platform.system() == 'Windows'. Reaction from other
platforms dependent on os.name == 'nt' (cygwin?) would be helpful.)
Finally, while I do not want to rush this - I would like to try and target
getting this complete in time for Python3.8
----------
components: Library (Lib), Tests
messages: 340155
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: cleanup the stdlib and tests with regard to sys.platform usage
versions: Python 3.8
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue36624>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
