On 29/05/2019 16:36, Ned Deily wrote:
> Ned Deily <nad@python.org> added the comment:
>
> FWIW, my opinion on making this kind of wholesale change has not changed: see the discussion in PR 7800. 

I had actually read through that before I started on this. Your closing
comments are here:
https://github.com/python/cpython/pull/7800#issuecomment-400182213

As someone who does not work 100% of the time with python - it is
extremely confusing and frustrating because there is no clear way of
doing something. From afar it appears as if platform.system() and
sys.platform evolved at different moments. I saw them as equivalent, and
only learned much later than one is build and the other is run-time.
And, there are very specific strings - that no longer match the current
situation.

Why, I ask myself, is it sometimes "darwin" (or is it "Darwin" - oh yes,
different test). And, I also ask myself - why did sys.platform "win"?
People did not like a function call (e.g., more resource intensive?) -
or was sys.platform "first" and platform.system() just never caught on?

I (think I) understand your concerns. While I would consider going
through the code to bring them in-line - that may be, for many reasons -
going too far.

I had hoped to: a) improve consistency and set a good example; as well
as b) be more than 'two constants' and in so-doing, provide a basis for
a grounded discussion.

As we stand now I still have a concern/question - is there any
willingness to work towards a solution - that can be (a basis of) a
clear definition of what "should" be. In a word - I consider the current
situation 'confusing'.

What is presented here does not have to be the solution. I hope everyone
will remember that this concern continues to popup. Saying no over and
over again does not solve anything - will not make it go away. Saying
no, repeatedly, may silence people.

All I can offer is my willingness to help.

Thank you for your time spent reading!

>  I think the changes made there were not an improvement for all the reasons stated, primarily because this now requires people reading the code base to learn *two* different ways of doing the same thing since these changes only affect the tests and not the platform-conditional code in the standard library modules themselves (which are not and should not be changed). Also, this means that backports of fixes from 3.8 will be complicated.  Note there ware already some "translation" errors detected and fixed in the PR re-spin; how many others remain?
>
> ----------
> nosy: +ned.deily
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue36624>
> _______________________________________
>