CONCERN: How to organize platform dependent blocks of code POLICY/RECOMMENDATION: (today) seems to be: arbitrary, although sys.platform, seems to be the favorite. * I, as 'python-consumer' was very surprised when I learned that sys.platform is "set" when Python is built - and that platform.system() was the call to make to get the run-time value. And, of course, they answered the "question" - what platform am I 'running' on, quite differently. * There are several - to many - issues in the past where, in one form or another, sys.platform, platform.system(), os.name, and I expect more but cannot think of them atm - used throughout all of Python. * A Python expert (e.g., core-devs) may understand - inherently - when each of these is the best option. As an 'experienced-novice' I am surprised that a "build-time constant" seems to be preference. This preference is not new (maybe platform.system() is "new", and os.name() too broad). * Zooming back to 2012 when "linux3" first appeared this became apparent that the build-time constant of linux2 was making 'things' difficult when the packaging was built on linux3 but running with applications developed on linux2 systems - and early on the move was made to just have "linux" returned (issue13236). For years the recommendation was (and maybe is?) to use sys.platform.startswith('linux'). * In between there have been other discussions - and the concern remains unresolved. * Personally, not "satisfied", and reluctant to "give up", or "ignore" something that continues to come up - I opened issue36624 to serve as a discussion point and worked through what would be needed to have "most" platforms testing against a CONSTANT defined in test.support - to provide an example of what it could look like. * As a non-expert - I EXPECT guidance from the people who know best why and when the different approaches are preferred. (I am hoping for something better than 'historical' or 'personal preferences'). * So, using this mail to python-dev to re-open the discussion - my suggested focus is NOT look at specific (test) code as it is now, but FOCUS from a perspective of Python3 and beyond - answering the 'concern' how should 'platform dependencies' be organized'. In other words, do not focus on an exception (although "listing" perceived exceptions will be helpful). Focus on "policy" aka "good practice". With that as a starting point discussing, understanding and validating exceptions to the guidelines will be much easier. -- as a 'mentoring' project - I am willing to do as much as I am able to "implement" something. My first PR was a 'stab in the dark' and I have already learned "other things" such as how to git rebase (read merge!). The discussion in the issue-tracker and PR conversation indicate to me that documentation of different approaches to organizing code dependencies is vital. And that it is not easily available. Devguide is one area - but 'core' documentation is more important imho - I read, and compare, the Python documentation much much more often than the devguide docs. Sincerely, Michael