[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Kubilay Kocak]

Change by Kubilay Kocak :


--
nosy: +koobs

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Michael Felt]

Michael Felt  added the comment:

On 06/06/2019 19:08, Steve Dower wrote:
> Steve Dower  added the comment:
>
> Changing our policy here (from "no policy" to "here's a recommendation") 
> probably deserves a python-dev discussion first.
I can rejoin the list - to follow the discussion, should one start.
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Steve Dower]

Steve Dower  added the comment:

Changing our policy here (from "no policy" to "here's a recommendation") 
probably deserves a python-dev discussion first.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Michael Felt]

Michael Felt  added the comment:

On 06/06/2019 14:14, Tal Einat wrote:
> Tal Einat  added the comment:
>
> Steve's suggestion sounds reasonable.
>
> Should we just add this to the devguide, then?

Well, as I said before - it was never about THIS being the solution.
While that would have been nice (for my ego). Would it be worthwhile,
assuming this moves to "devguide" status - for me to work through the
tests - looking for the tests that do not follow these guidelines and
"patch" those?

Probably minor, but it is something I could do. Think of it as
"self-documentation" rather than .rst files.

>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Tal Einat]

Tal Einat  added the comment:

Steve's suggestion sounds reasonable.

Should we just add this to the devguide, then?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Steve Dower]

Steve Dower  added the comment:

The reason I'd prefer sys.platform in most cases is because it's a compile-time 
constant, based on the one that includes/excludes APIs near completely, and 
most of our tests ought to be switching on these.

I personally don't see any need to switch on os.name, except perhaps in the 
tests for that module.

But if we start skipping tests based on platform(), then we will miss out on 
seeing new failures on new platforms. This is a real concern, as I have 
colleagues currently adding Windows on ARM and ARM64 support, and since the API 
is the same we expect everything to work. It doesn't, of course, but that's 
what specific exclusions are for.

If I were to propose a consistent scheme for this, I'd suggest:
* include tests based on sys.platform
* skip tests based on platform module

So if some functionality only exists when MS_WINDOWS was defined, we check 
sys.platform == win32. But if it doesn't work on ARM, we check 
platform.platform == (whatever the value is).

That way, adding new platforms will get the maximum amount of tests initially.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Michael Felt]

Michael Felt  added the comment:

On 05/06/2019 07:07, Tal Einat wrote:
> Tal Einat  added the comment:
>
> Michael, your willingness to help, and the work on this issue and PR, are 
> greatly appreciated!
>
> Reading through the discussion here again, and the one referenced by Ned, I 
> tend to agree with the point that having *yet another* spelling for OS 
> checking is perhaps not a good idea.  The point that needing to see exactly 
> which check is done in certain edge-cases is another good point against 
> adding such new constants.  Moreover, regardless of my opinion, there isn't a 
> consensus and at this point I don't think there will be.
>
> Considering the above, perhaps it would be better to use only a single, 
> "canonical" idiom throughout the tests, or at least from this point forward 
> (to avoid a codebase-wide change)? Steve Dower said he would "prefer 
> sys.platform to be canonical".
>
> I do suffer from having all of os.name, sys.platform and platform.system() 
> used in various places, and it not being clear when one should be used 
> instead of another.

>From experience, for AIX, and I think also for windows, not sure about
darwin, oops - macos (or is that macOS) the confusion I faced was that
sys.platform returns the value the system was built on, not what it is
running on. If I was an application developer I would be more interested
in the platform it is running on. "Lucky me!" - starting with Python3.8
sys.platform will say "aix" rather than aixX. Likely there could have
been differences between aix3 and aix4 (e.g., the kernel changed from
"static" to "dynamic" driver extensions) that might have influenced
Python - but not since AIX5 - and AIX "binary compatibility" assurances
when using shared libraries (from IBM, e.g. libc).

More to the point - we all suffer - and some kind of direction is
needed. Beyond my pay grade - so I'll accept whatever is decided (even
if that is indecesion). As I said before - "lucky me", the core is
"resolved" for AIX (platform.system() == 'AIX', and sys.platform ==
'aix') - just as it is for "linux". This remains 'not resolved' for many
other platforms.

Further, imho - having it defined as a "constant" is not "yet another
spelling". Instead, it moves us towards a "canonical" idiom.

I have said before, and I'll say again - I am willing to do the manual
backport, learn more about git as I do so (;P) - and I'll even
"maintain" this, should this be any additional "help" is working towards
a canonical/uniform (or should I say PEP) to establish the RUNNING platform.

Regards,

Michael

> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Tal Einat]

Tal Einat  added the comment:

Michael, your willingness to help, and the work on this issue and PR, are 
greatly appreciated!

Reading through the discussion here again, and the one referenced by Ned, I 
tend to agree with the point that having *yet another* spelling for OS checking 
is perhaps not a good idea.  The point that needing to see exactly which check 
is done in certain edge-cases is another good point against adding such new 
constants.  Moreover, regardless of my opinion, there isn't a consensus and at 
this point I don't think there will be.

Considering the above, perhaps it would be better to use only a single, 
"canonical" idiom throughout the tests, or at least from this point forward (to 
avoid a codebase-wide change)? Steve Dower said he would "prefer sys.platform 
to be canonical".

I do suffer from having all of os.name, sys.platform and platform.system() used 
in various places, and it not being clear when one should be used instead of 
another.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Michael Felt]

Michael Felt  added the comment:

On 29/05/2019 16:36, Ned Deily wrote:
> Ned Deily  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 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Ned Deily]

Ned Deily  added the comment:

FWIW, my opinion on making this kind of wholesale change has not changed: see 
the discussion in PR 7800.  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Tal Einat]

Tal Einat  added the comment:

There a cleanly rebased PR up at GH-13648.

I'd like to get opinions from additional people about this now that the PR is 
ready. Steve? Victor?


Some discussion which happened in PR comments:

Andrew Svetlov approved the changes for the asyncio tests.

Stefan Krah asked to revert the changes in test_decimal, saying "I don't quite 
like this change.". Michael Felt argued "imho - this adds clarity to the 
whole", to which Stefan replied: "I don't think so: Now I have to wonder which 
of the different idioms hides behind MS_WINDOWS. And in other project's 
setup.py files I still need sys.platform, so now there's even one additional 
way to accomplish the same thing."

Michael followed up with additional arguments in favor of this change, which 
are rather verbose, but can be summed up as saying that this adds clarity and 
uniformity throughout the tests.

--
nosy: +taleinat

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Tal Einat]

Change by Tal Einat :


--
pull_requests: +13542
pull_request: https://github.com/python/cpython/pull/13648

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Michael Felt]

Michael Felt  added the comment:

On 23/04/2019 17:53, Steve Dower wrote:
> Steve Dower  added the comment:
>
>> Being 'runtime' rather than 'buildtime' seemed more precise - tests that
>> are not meant to be build-time dependent use run-time status while
>> leaving sys.platform for concerns that are directly related to builds
> This is a good point - perhaps we need both?
>
> Many of the current test skips are related to build-time switches, but 
> indeed, some relate to the runtime environment.
>
> One aspect I'm keeping in mind here is that with the Windows Subsystem for 
> Linux, many lines are becoming blurred with respect to which build of Python 
> people are using (I'm already getting bug reports from people who thought 
> they were getting the Windows build but actually the Linux one, or vice 
> versa). And mismatching builds causes some weird problems. Being able to 
> clearly identify "Windows build + WSL environment" or "Linux build + WSL 
> environment" will likely matter more over time.
>
> It would be nice to have all the checks centralized, perhaps a set of 
> decorators in a test.requires module?
>
> @test.requires.linux_platform
> @test.requires.darwin_platform
> @test.requires.macos_runtime(10, 9)
> def test_my_test(self): ...
>
> (It would require some clever decorator design, but we can make those work 
> like "ORs" rather than "ANDs".)
>
> Does it provide any benefit? I think it's clever,
Too clever for me to build. There is a lot about the Python language
(syntax) I do not understand well enough.
> but that doesn't mean it's worthwhile :) Using skipIf and skipUnless with 
> test.support.CONSTANTS is just as readable and just as obvious (once we're 
> using them consistently).

To that end, I modified another 60 lines, or so, of mainly sys.platform
== 'win32' to use MS_WINDOWS, not MS_WINDOWS, skipIf(MS_WINDOWS,...) or
SkipUnless(MS_WINDOWS,...) - or comparable for the other platforms.

I also replaced the use of (support.)is_android and (support.is_java)
with ANDROID and JYTHON.

Curious about comments from code owners. And suggestions re: the
sys.platform lines (roughly 50) that are left.

FYI: when I started there were 321 references to sys.platform with
roughly 315 involved in a string comparison of some kind. Now it is
closer to 50.

>
> 
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Steve Dower]

Steve Dower  added the comment:

> Being 'runtime' rather than 'buildtime' seemed more precise - tests that
> are not meant to be build-time dependent use run-time status while
> leaving sys.platform for concerns that are directly related to builds

This is a good point - perhaps we need both?

Many of the current test skips are related to build-time switches, but indeed, 
some relate to the runtime environment.

One aspect I'm keeping in mind here is that with the Windows Subsystem for 
Linux, many lines are becoming blurred with respect to which build of Python 
people are using (I'm already getting bug reports from people who thought they 
were getting the Windows build but actually the Linux one, or vice versa). And 
mismatching builds causes some weird problems. Being able to clearly identify 
"Windows build + WSL environment" or "Linux build + WSL environment" will 
likely matter more over time.

It would be nice to have all the checks centralized, perhaps a set of 
decorators in a test.requires module?

@test.requires.linux_platform
@test.requires.darwin_platform
@test.requires.macos_runtime(10, 9)
def test_my_test(self): ...

(It would require some clever decorator design, but we can make those work like 
"ORs" rather than "ANDs".)

Does it provide any benefit? I think it's clever, but that doesn't mean it's 
worthwhile :) Using skipIf and skipUnless with test.support.CONSTANTS is just 
as readable and just as obvious (once we're using them consistently).



--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Michael Felt]

Michael Felt  added the comment:

On 22/04/2019 21:14, Steve Dower wrote:
> Steve Dower  added the comment:
>
> I like this, though I don't like using the platform module here and would 
> prefer sys.platform to be canonical (until there's a need to differentiate - 
> e.g. some tests coming for Windows ARM32 will need to be more specific).

I thought I would try `platform` as that already seemed to be more
portable over different versions (e.g., linux3, linux4, linux5, aix4,
aix5, aix7 coming from sys.platform while platform.system() was already
'Linux' and 'AIX' respectively). Personally, it makes difference to me.
Being 'runtime' rather than 'buildtime' seemed more precise - tests that
are not meant to be build-time dependent use run-time status while
leaving sys.platform for concerns that are directly related to builds
(e.g., cross-platform-builds; when adding modules using eggs or pip
where the module may want a "build-platform" dependency; etc).

In either case - I do believe in a 'canonical' statement - that could be
(later) documented in a PEP (e.g., update to PEP 8 if that is also
applicable to test writing).

Looking forward - question - should the same canon be applied within the
core? Here is "merely" looking at Lib/test

>
> In general, I'd like fewer tests to be platform specific and make more 
> functionality "just work" across platforms, or at least platform families. I 
> feel like more precise skips don't actually help with that - they make it too 
> easy to say "this functionality just doesn't work here" instead of trying to 
> make it work.

Agreed. Although there shall always be some platform differences. Some
"platform functions" will be absent or at least different.

Not directly related perhaps, but is a function absent as a "platform"
function when it is only available after a third-party (aka "asis")
library is installed? I, personally, have a hard time identifying what
is really "core" - asin - must be present for Python to be Python,
versus must be present to support a more (or less) commonly used 'module'.

I'll wait a bit for any other comments - and I am curious about thoughts
for the platforms 'ignored', e.g., hpux, cygwin, vmax(?), and a few more.

Maybe the "common wisdom" is that the exceptions for the special
platforms that are here - should just be removed - looking forward.
Perhaps being restored because someone working on (supporting) that
platform requests it being restored. I would hope this would also help
to further clean up the tests.

>
> --
> nosy: +steve.dower
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Steve Dower]

Steve Dower  added the comment:

I like this, though I don't like using the platform module here and would 
prefer sys.platform to be canonical (until there's a need to differentiate - 
e.g. some tests coming for Windows ARM32 will need to be more specific).

In general, I'd like fewer tests to be platform specific and make more 
functionality "just work" across platforms, or at least platform families. I 
feel like more precise skips don't actually help with that - they make it too 
easy to say "this functionality just doesn't work here" instead of trying to 
make it work.

--
nosy: +steve.dower

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Michael Felt]

Michael Felt  added the comment:

Never mind - typos in the files I did work on. iow, I found a way to get the 
filename, and am cleaning up the errors.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Michael Felt]

Michael Felt  added the comment:

OK. I have been chewing my bone. I hope not too much indigestion.

Who has a pointer for the antacid?

Getting base branch for PR ... origin/master
Getting the list of files that have been added/changed ... 72 files
Fixing Python file whitespace ... Traceback (most recent call last):
  File "../git/python3-3.8/Tools/scripts/patchcheck.py", line 285, in 
main()
  File "../git/python3-3.8/Tools/scripts/patchcheck.py", line 253, in main
normalize_whitespace(python_files)
  File "../git/python3-3.8/Tools/scripts/patchcheck.py", line 35, in call_fxn
result = fxn(*args, **kwargs)
  File "../git/python3-3.8/Tools/scripts/patchcheck.py", line 149, in 
normalize_whitespace
fixed = [path for path in file_paths if path.endswith('.py') and
  File "../git/python3-3.8/Tools/scripts/patchcheck.py", line 150, in 
reindent.check(os.path.join(SRCDIR, path))]
  File "/data/prj/python/git/python3-3.8/Tools/scripts/reindent.py", line 138, 
in check
if r.run():
  File "/data/prj/python/git/python3-3.8/Tools/scripts/reindent.py", line 203, 
in run
for _token in tokens:
  File "/data/prj/python/git/python3-3.8/Lib/tokenize.py", line 521, in 
_tokenize
raise TokenError("EOF in multi-line statement", (lnum, 0))
tokenize.TokenError: ('EOF in multi-line statement', (694, 0))
make: 1254-004 The error code from the last command is 1.

In other words - I have not changed the file 'complaining', but have changed 
many files. Likely, a new issue - however, I would like to move forward with 
this one.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Michael Felt]

Change by Michael Felt :


--
keywords: +patch
pull_requests: +12768
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Michael Felt]

Michael Felt  added the comment:

On 15/04/2019 11:50, STINNER Victor wrote:
> STINNER Victor  added the comment:
>
> support.is_android has two flaws:
>
> * it's a constant: it must be spelled as UPPER CASE
> * I dislike "is_" prefix: "MS_WINDOWS" constant is commonly used, and it 
> doesn't start with "is_".

I do not like the is_xxx form either, but I am low in the (name) picking
order. I like ALL_CAPS because it is easier to recognize as a constant,

I have the habit of using _ (underscore) before a name - but the clear
consensus is to not use that for constants coming from support.test.

As to being 'backported', even manually - that is something I would work
on. I am an old dog - and this seems like a good enough bone for me.

So, I'll finish up for AIX - except I would like to underline again
something I have come across a few times (but cannot find right now) -
and that is to base these constants not on the platform being built on,
but the platform being run on (i.e., platform.system()). I expect there
may be specific tests that are relevant during the build moment, or
perhaps, "later", when using something such as 'pip' to add a module.

As, relatively speaking, a new-comer to Python, I see this as a vast
improvement to the readability (and clarity) of the code.

As to new tests, modifications, etc. it will become part of the PR
review to be sure this becomes and stays the standard.

Anyway, I'll get started with AIX - not that many - and I hope with all
the constant definitions being moved to one place that should simplify
maintenance (and perhaps even back-porting).

>
> In my PR, I used support.ANDROID.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[STINNER Victor]

STINNER Victor  added the comment:

support.is_android has two flaws:

* it's a constant: it must be spelled as UPPER CASE
* I dislike "is_" prefix: "MS_WINDOWS" constant is commonly used, and it 
doesn't start with "is_".

In my PR, I used support.ANDROID.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[STINNER Victor]

STINNER Victor  added the comment:

My previous attempt was: https://github.com/python/cpython/pull/7800

Serhiy Storchaka and Ned Deily were unable about this change:

* https://github.com/python/cpython/pull/7800#issuecomment-398688441
* https://github.com/python/cpython/pull/7800#issuecomment-399614918
* https://github.com/python/cpython/pull/7800#issuecomment-400134294

*If* a change is done, I would prefer to do it for Linux, macOS and Windows as 
well.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Michael Felt]

Michael Felt  added the comment:

On 14/04/2019 18:04, Michael Felt wrote:
> Is this a good way to get started?

So, as an example - seems to be many attributes in test/support/__init__.py

diff --git a/Lib/test/support/__init__.py b/Lib/test/support/__init__.py
index 5bd15a2..e20567f 100644
--- a/Lib/test/support/__init__.py
+++ b/Lib/test/support/__init__.py
@@ -101,6 +101,8 @@ __all__ = [
 # network
 "HOST", "IPV6_ENABLED", "find_unused_port", "bind_port",
"open_urlresource",
 "bind_unix_socket",
+    # platform
+    "is_aix",
 # processes
 'temp_umask', "reap_children",
 # logging
@@ -815,6 +817,7 @@ requires_bz2 = unittest.skipUnless(bz2, 'requires bz2')
 requires_lzma = unittest.skipUnless(lzma, 'requires lzma')

 is_jython = sys.platform.startswith('java')
+is_aix = platform.system() == 'AIX'

 is_android = hasattr(sys, 'getandroidapilevel')

diff --git a/Lib/test/test_c_locale_coercion.py
b/Lib/test/test_c_locale_coercion.py
index 35272b5..0685ed8 100644
--- a/Lib/test/test_c_locale_coercion.py
+++ b/Lib/test/test_c_locale_coercion.py
@@ -10,6 +10,7 @@ import unittest
 from collections import namedtuple

 from test import support
+is_aix = support.is_aix
 from test.support.script_helper import (
 run_python_until_end,
 interpreter_requires_environment,
@@ -40,7 +41,7 @@ if sys.platform.startswith("linux"):
 # TODO: Once https://bugs.python.org/issue30672 is addressed,
we'll be
 #   able to check this case unconditionally
 EXPECTED_C_LOCALE_EQUIVALENTS.append("POSIX")
-elif sys.platform.startswith("aix"):
+elif is_aix:
 # AIX uses iso8859-1 in the C locale, other *nix platforms use ASCII
 EXPECTED_C_LOCALE_STREAM_ENCODING = "iso8859-1"
 EXPECTED_C_LOCALE_FS_ENCODING = "iso8859-1"

I had originally been thinking using _AIX, but the convention seems to
be is_xyzsomething.

Comments welcome.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Michael Felt]

Michael Felt  added the comment:

I took a peak at test.support.

a) I see that while many tests import test.support, or from test.support import 
 - not all tests use this.

b) I see that only 35 .py files in Lib/test have the string 
sys.platform.startswith, and there are 76 files that have sys.platform (so, 
there are roughly 40 files that have sys.platform without startswith).

I can start by adding _AIX to test.support and adding (as needed) from 
test.support import _AIX (and later _Linux, _Darwin) in the "35" files. If that 
seems to be working - and looking - proper the other 40 files could be added to 
the change.

Is this a good way to get started?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[STINNER Victor]

STINNER Victor  added the comment:

I tried to add constants to test.support once to identify operating systems, 
nbut I had to revert the change. I am not sure that there is any problem here. 
Leaving the code unchanged is also fine :-)

--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Michael Felt]

New submission from Michael Felt :

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() - 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 ==  but should 
be platform.system() == , 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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com