[issue42367] Restore os.makedirs ability to apply mode to all directories created
Change by JustAnotherArchivist : -- nosy: +JustAnotherArchivist ___ Python tracker <https://bugs.python.org/issue42367> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43634] Extensions build does not respect --jobs setting
New submission from JustAnotherArchivist : The extension building does not respect the --jobs option passed to make. Specifically, in that step, `python setup.py build` always spawns as many gcc processes as there are CPU cores available regardless of that option. This caused problems for me because I have a VM that sees all host machine CPU cores but only has a limited amount of RAM. Despite running `make -j 4`, many more gcc processes are spawned, and this immediately causes memory starvation and a system freeze after a few seconds. The reason for this is that setup.py blindly enables parallelism in the extension compilation if '-j' appears in the MAKEFLAGS at 3.9.2/setup.py:355. Later on, distutils uses os.cpu_count to set the worker count, i.e. the '-j' *value* is ignored. This behaviour was first introduced with #5309 as far as I can see, though I haven't tested anything other than version 3.9.2. Hacky workaround: patching the above setup.py line to `self.parallel = 4`. Cf. https://github.com/pyenv/pyenv/issues/1857 -- components: Build messages: 389558 nosy: JustAnotherArchivist priority: normal severity: normal status: open title: Extensions build does not respect --jobs setting type: resource usage versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18233] SSLSocket.getpeercertchain()
Change by JustAnotherArchivist : -- nosy: +JustAnotherArchivist ___ Python tracker <https://bugs.python.org/issue18233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32528] Change base class for futures.CancelledError
Change by JustAnotherArchivist : -- pull_requests: +20619 pull_request: https://github.com/python/cpython/pull/21474 ___ Python tracker <https://bugs.python.org/issue32528> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32528] Change base class for futures.CancelledError
JustAnotherArchivist added the comment: As another datapoint, this also broke some of my code on 3.8 because I was using `concurrent.futures.CancelledError` rather than `asyncio.CancelledError` to handle cancelled futures. And I'm certainly not the only one to have done this given that it's mentioned in at least two Stack Overflow answers: https://stackoverflow.com/a/38655063 and https://stackoverflow.com/a/36277556 While I understand the rationale behind this change, it would've been good to include this inheritance detail in the 3.8 release notes. ------ nosy: +JustAnotherArchivist ___ Python tracker <https://bugs.python.org/issue32528> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41275] Clarify whether Futures can be awaited multiple times
New submission from JustAnotherArchivist : While the situation is clear regarding coroutine objects (#25887), as far as I can see, the documentation doesn't specify whether asyncio.Futures can be awaited multiple times. The code has always (at least since the integration into CPython) allowed for it since Future.__await__ simply returns Future.result() if it is already done. Is this guaranteed/intended behaviour, as also implied by some of the comments on #25887, or is it considered an implementation detail? Here are the only two things I found in the documentation regarding this: > library/asyncio-task: When a Future object is awaited it means that the > coroutine will wait until the Future is resolved in some other place. > library/asyncio-future: Future is an awaitable object. Coroutines can await > on Future objects until they either have a result or an exception set, or > until they are cancelled. Neither of these say anything about awaiting a Future that is already resolved, i.e. has a result, has an exception, or was cancelled. If this is intended to be guaranteed, it should be mentioned in the Future documentation. If it is considered an implementation detail, it's probably not necessary to explicitly mention this anywhere, but it might be a good idea to add another line to e.g. the asyncio.wait example on how to correctly retrieve the result of an already-awaited Future/Task. -- components: asyncio messages: 373504 nosy: JustAnotherArchivist, asvetlov, yselivanov priority: normal severity: normal status: open title: Clarify whether Futures can be awaited multiple times type: enhancement ___ Python tracker <https://bugs.python.org/issue41275> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
