[Python-Dev] Re: [SPAM] Re: Move support of legacy platforms/architectures outside Python
On Tue, 23 Feb 2021 16:45:27 + Rob Boehne wrote: > On 2/22/21, 4:06 PM, "Antoine Pitrou" wrote: > > On Mon, 22 Feb 2021 19:50:43 + > Rob Boehne wrote: > > > > The other thing that crept into this thread was the mention of test > that intermittently fail. > > That's a huge problem because it suggests that applications will > sometimes fail. > > I have usually seen these sort of issues because of > > 1) Uninitialized memory being used (read) > > 2) Threading problems > > 3) Resources used (files, networking, daemons) but unavailable > > 4) memory mis-management (buffer overrun that doesn't cause a crash) > > > > #3 is probably best fixed by testing for resources and skipping when > unavailable > > 5) Poor quality POSIX support in the target platform. The Python test > suite is actually quite demanding in this regard (except on Windows). > > Regards > > Antoine. > > > > Antoine: > > I find this a bit of a surprise, can you give an example of poor POSIX > support leading to intermittent test failures? Hmm, I don't have any precise examples off the top of my head (that was several years ago), but issues mixing pthreads, signals and/or fork come to mind. OpenBSD was quite bad at that especially. Regards Antoine. ___ 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/4TOL7P47UBAYOXOFM2C3RTWGTJFWMHYU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [SPAM] Re: Move support of legacy platforms/architectures outside Python
On 2/22/21, 4:06 PM, "Antoine Pitrou" wrote: On Mon, 22 Feb 2021 19:50:43 + Rob Boehne wrote: > > The other thing that crept into this thread was the mention of test that intermittently fail. > That's a huge problem because it suggests that applications will sometimes fail. > I have usually seen these sort of issues because of > 1) Uninitialized memory being used (read) > 2) Threading problems > 3) Resources used (files, networking, daemons) but unavailable > 4) memory mis-management (buffer overrun that doesn't cause a crash) > > #3 is probably best fixed by testing for resources and skipping when unavailable 5) Poor quality POSIX support in the target platform. The Python test suite is actually quite demanding in this regard (except on Windows). Regards Antoine. Antoine: I find this a bit of a surprise, can you give an example of poor POSIX support leading to intermittent test failures? Thanks, Rob Boehne ___ 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/5XXXKPQCF2OTXLKYOJ5AJIW27M3OUHY3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [SPAM] Re: Move support of legacy platforms/architectures outside Python
On 2/22/21, 1:39 PM, "Steve Dower" wrote: On 2/22/2021 5:18 PM, Matthias Klose wrote: > On 2/21/21 1:13 PM, Victor Stinner wrote: > Document what is supported, be inclusive about anything else. Don't make a > distinction yet between legacy and upcoming new architectures. I agree with this, and I don't see any reason why we shouldn't just use the list of stable buildbot platforms as the "supported" list. That makes it really clear what the path is to push support onto upstream (join up and bring a buildbot with you), and also means that we've got a physically restricted set of machines to prove work before doing a release. Actively blocking anything at all seems unnecessary at the source/build level. That's for pre-built binaries and other conveniences. Cheers, Steve ___ +1 to this. I use a few unsupported platforms, not as a hobby, but in my work. I generally don't require ALL the things in python to work on these platforms, so even if I were to contribute a buildbot for an obscure (but definitely not "hobby") platform, it's implied that I would also need to fix test failures in modules I don't use. I generally need to provide some reason for me to use my employer's time, so I can't really justify fixing test failures in code the company doesn't use. I think these users are just asking that what currently works not be broken intentionally, and that follows the spirit of Autoconf, to test if something works and enable if it when it does. There are also other ways to reduce the burden of maintaining a large number of platforms, such as abstracting away the OS services. The other thing that crept into this thread was the mention of test that intermittently fail. That's a huge problem because it suggests that applications will sometimes fail. I have usually seen these sort of issues because of 1) Uninitialized memory being used (read) 2) Threading problems 3) Resources used (files, networking, daemons) but unavailable 4) memory mis-management (buffer overrun that doesn't cause a crash) #3 is probably best fixed by testing for resources and skipping when unavailable The others are problems in the code, and can be fixed with clang sanitizers, but Without some routine running of them, those sorts of problems will reappear. ___ 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/6VCZYPSIB4QE3FL4L3D2WER3VU3LZGCO/ Code of Conduct: http://python.org/psf/codeofconduct/
