On 22/04/2019 21:14, Steve Dower wrote:
> Steve Dower <steve.dower@python.org> 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 <report@bugs.python.org>
> <https://bugs.python.org/issue36624>
> _______________________________________
>