[Python-Dev] Failing tests on master (asyncio, multiprocessing)
Hi, several of my PRs as well as local tests have started failing recently. On my local Fedora 27 machine, four sendfile related tests of test_asyncio's BaseLoopSockSendfileTests suite are failing reproducible. For example Travis CI job https://travis-ci.org/python/cpython/jobs/380852981 fails in: * test_stdin_broken_pipe (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) * test_stdin_broken_pipe (test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests) * test_ignore (test.test_multiprocessing_forkserver.TestIgnoreEINTR) Could somebody have a look, please? Christian ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP: 576 Title: Rationalize Built-in function classes
Hi, At the language summit this year, there was some discussion of PEP 575. I wanted to simplify the PEP, but rather than modify that PEP, Nick Coghlan encouraged me to write an alternative PEP instead. PEP 576 aims to fulfill the same goals as PEP 575, but with fewer changes and to be fully backwards compatible. The PEP can be viewed here: https://github.com/python/peps/blob/master/pep-0576.rst Cheers, Mark. P.S. I'm happy to have discussion of this PEP take place via GitHub, rather than the mailing list, but I thought I would follow the conventional route for now. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failing tests on master (asyncio, multiprocessing)
On 19 May 2018 at 02:05, Christian Heimes wrote: > Hi, > > several of my PRs as well as local tests have started failing recently. > On my local Fedora 27 machine, four sendfile related tests of > test_asyncio's BaseLoopSockSendfileTests suite are failing reproducible. > https://bugs.python.org/issue33531 ? -- Eitan Adler ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failing tests on master (asyncio, multiprocessing)
On 2018-05-19 11:29, Eitan Adler wrote: > On 19 May 2018 at 02:05, Christian Heimes wrote: >> Hi, >> >> several of my PRs as well as local tests have started failing recently. >> On my local Fedora 27 machine, four sendfile related tests of >> test_asyncio's BaseLoopSockSendfileTests suite are failing reproducible. >> > > https://bugs.python.org/issue33531 ? Yeah, that's it. Thanks! Christian ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: 576 Title: Rationalize Built-in function classes
mark schrieb am 19.05.2018 um 11:15: > At the language summit this year, there was some discussion of PEP 575. > I wanted to simplify the PEP, but rather than modify that PEP, Nick Coghlan > encouraged me to write an alternative PEP instead. > > PEP 576 aims to fulfill the same goals as PEP 575, but with fewer changes > and to be fully backwards compatible. > > The PEP can be viewed here: > > https://github.com/python/peps/blob/master/pep-0576.rst Quick question, since the PEP doesn't say it explicitly. I assume that the builtin function type would be subclassable, right? That would suggest that it also needs a type flag bit for fast type checking. Basically, subclassing still seems necessary in order to support closure state, non-constant default arguments, etc. Stefan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 575 (Unifying function/method classes) update
On 17 May 2018 at 06:34, Jeroen Demeyer wrote: > On 2018-05-16 17:31, Petr Viktorin wrote: > >> The larger a change is, the harder it is to understand >> > > I already disagree here... > > I'm afraid that you are still confusing the largeness of the *change* with > the complexity of the *result* after the change was implemented. > That's not how code reviews work, as their complexity is governed by the number of lines changed (added/removed/modified), not just the number of lines that are left at the end. That said, "deletes more lines than it adds" is typically a point strongly in favour of a particular change. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] "make test" routinely fails to terminate
On the 3.7 branch, "make test" routinely fails to terminate. (Pretty vanilla Ubuntu 17.10 running on a Dell Laptop. Nothing esoteric at all) Lately, it's been one of the multiprocessing tests. After a long while (~2000 seconds), I kill it, then it complains many times about lack of a valid_signals attribute in the signal module: == ERROR: test_remove_signal_handler_error2 (test.test_asyncio.test_unix_events.SelectorEventLoopSignalTests) -- Traceback (most recent call last): File "/home/skip/src/python/cpython/Lib/unittest/mock.py", line 1191, in patched return func(*args, **keywargs) File "/home/skip/src/python/cpython/Lib/test/test_asyncio/test_unix_events.py", line 219, in test_remove_signal_handler_error2 m_signal.valid_signals = signal.valid_signals AttributeError: module 'signal' has no attribute 'valid_signals' -- Ran 1967 tests in 36.058s FAILED (errors=362, skipped=11) test test_asyncio failed /home/skip/src/python/cpython/Lib/asyncio/base_events.py:605: ResourceWarning: unclosed event loop <_UnixSelectorEventLoop running=False closed=False debug=False> source=self) Re-running test 'test_signal' in verbose mode then reruns test_signal in verbose mode. Earlier today, a run succeeded, so I'm guessing a race condition exists in the test system. I recall encountering a similar problem a few weeks ago and discovered this open ticket: https://bugs.python.org/issue33099 Should I expect this as the normal behavior? Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
