Michael Felt <aixto...@felt.demon.nl> added the comment:
On 29/05/2019 16:36, Ned Deily wrote: > Ned Deily <n...@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 <rep...@bugs.python.org> > <https://bugs.python.org/issue36624> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36624> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
