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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YCZYPRBRNOCXLBJ42HA6QZHIBCKZDTGD/
