[issue30718] [doc] open builtin function: specifying the size of buffer has no effect for text files

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 4.0 -> 5.0 pull_requests: +30403 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32351 ___ Python tracker <https://bugs.python.org/i

[issue46168] Incorrect format specified for the "style" key in the configuration file format formatter example

Stanley added the comment: Samriddhi, are you still working on this? -- nosy: +slateny ___ Python tracker <https://bugs.python.org/issue46168> ___ ___ Python-bug

[issue44158] Clarify documentation for redirected stdout/stderr when using subprocess in Linux

Stanley added the comment: Hmm, I'm not quite following - when you say that the subproccess-ed command should also inherit the redirection, which subprocess command are you referring to, and nested or unnested? I gave it a ran and everything seems to run how I'd expected it, so

[issue47207] Switch datetime docstrings / documentation to using "Returns" rather than "Return"?

Stanley added the comment: Is there a bpo page or some sort that discusses why the imperative mood is used over the indicative mood other than convention of PEP 257? I found this (https://mail.python.org/pipermail/tutor/2012-May/089584.html) question and answer that seems to make sense, but

[issue32658] Metacharacter (\) documentation suggestion

Stanley added the comment: Feel free, it's all yours -- ___ Python tracker <https://bugs.python.org/issue32658> ___ ___ Python-bugs-list mailing list

[issue32658] Metacharacter (\) documentation suggestion

Stanley added the comment: Mike, are you still working on this issue? -- nosy: +slateny ___ Python tracker <https://bugs.python.org/issue32658> ___ ___ Pytho

[issue39971] [doc] Error in functional how-to example

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 4.0 -> 5.0 pull_requests: +30250 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/32172 ___ Python tracker <https://bugs.python.org/i

[issue37430] [doc] range is not a built-in function

Stanley added the comment: Terry, how do you think the example/paragraph should be improved? I notice that the previous paragraphs talk about continue/break/else, so were you looking for some new example with all those? And I think the indexing's been fixed by now, but a clickable li

[issue47031] math.nan should note that NANs do not compare equal to anything

Stanley added the comment: Then perhaps saying that it's *never* equal is too strong, and instead we just say it's *not* equal. Not too sure how to phrase the behavior difference between `==` and `is` though, if that's something that

[issue47031] math.nan should note that NANs do not compare equal to anything

Stanley added the comment: Vedran's got a good point, as existing documentation for math.nan already says "... Equivalent to the output of float('nan')." so it does seem a bit redundant to say both, though I wonder if we should still be explicit since >&g

[issue33028] [doc] tempfile.TemporaryDirectory documentation improvements

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 4.0 -> 5.0 pull_requests: +30104 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32016 ___ Python tracker <https://bugs.python.org/i

[issue47031] math.nan should note that NANs do not compare equal to anything

Stanley added the comment: How does this sound instead? The unequalness is pushed to the front and the IEEE part back so it's less likely missed: Math.nan and float('nan') are never equal to any other value, including themselves, as per IEEE 754. Use math.isnan t

[issue9182] document “--” as a way to distinguish option w/ narg='+' from positional argument in argparse

Change by Stanley : -- nosy: +slateny nosy_count: 13.0 -> 14.0 pull_requests: +29908 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31810 ___ Python tracker <https://bugs.python.org/

[issue9305] Don't use east/west of UTC in date/time documentation

Change by Stanley : -- nosy: +slateny nosy_count: 14.0 -> 15.0 pull_requests: +29817 pull_request: https://github.com/python/cpython/pull/31697 ___ Python tracker <https://bugs.python.org/iss

[issue26545] [doc] os.walk is limited by python's recursion limit

Stanley added the comment: I'm not too sure about documenting the recursive limit here. There's a few other recursive functions in the os library (such as makedirs()) and if we note the recursive limit for os.walk then all of them should be noted too, but that doesn't seem qu

[issue18534] [doc] State clearly that open() 'file' param is "name" attr of the result

Stanley added the comment: Would it be fine to modify FileIO.name like this: "... given in the constructor. Depending on the type of *name* that was passed into the constructor, this may not necessarily e a string." -- nosy: +slateny

[issue23323] [doc] mention that flags arg to imaplib's append should be a string

Stanley added the comment: How would this sound as clarification for the flags argument? *flags* is a space-separated string containing IMAP flags tokens. Must start with ``\``. Perhaps optionally also provide the list of system flags as given in https://datatracker.ietf.org/doc/html

[issue25415] [doc] "there is no public constructor" should be reworded in io module documentation

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 5.0 -> 6.0 pull_requests: +29753 pull_request: https://github.com/python/cpython/pull/31631 ___ Python tracker <https://bugs.python.org/issu

[issue10149] [doc] Data truncation in expat parser

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 6.0 -> 7.0 pull_requests: +29752 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31629 ___ Python tracker <https://bugs.python.org/i

[issue45991] Improve ambiguous docstrings in pkgutil

Stanley added the comment: I feel like there might be some backwards compatibility issues if pkgutil wraps it like that, but similarly I'm not at all familiar with how common the package is used and whether it'd be fine to make that change, so I'll also differ

[issue23453] [doc] Clarify bytes vs text with non-seeking tarfile stream

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 3.0 -> 4.0 pull_requests: +29733 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31610 ___ Python tracker <https://bugs.python.org/i

[issue25743] [doc] Clarify exactly what \w matches in UNICODE mode

Stanley added the comment: Would a change like this be accurate? Matches Unicode word characters; this includes most alphanumeric characters as well as the underscore. In Unicode, alphanumeric characters are defined to be the general categories L + N (see https://unicode.org/reports/tr44

[issue20970] [doc] contradictory documentation for prog option of argparse

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 6.0 -> 7.0 pull_requests: +29725 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31602 ___ Python tracker <https://bugs.python.org/i

[issue29251] [doc] Class __dict__ is only a mapping proxy

Stanley added the comment: >From what I can see, the original patch changed ... and the *dict* dictionary is the namespace containing definitions for class body and is copied to a standard dictionary to become the __dict__ attribute into this ... and the *dict* dictionary is copied to

[issue13821] [doc] misleading return from isidentifier

Stanley added the comment: For clarification then, would it be accurate to add a sentence like this in the documentation? "Note that isidentifier() still returns True even if the string may not be normalized." -- nosy: +slateny

[issue21761] [doc] language reference describes the role of module.__file__ inaccurately

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 6.0 -> 7.0 pull_requests: +29687 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31565 ___ Python tracker <https://bugs.python.org/i

[issue27583] [doc ] configparser: modifying default_section at runtime

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 5.0 -> 6.0 pull_requests: +29685 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31562 ___ Python tracker <https://bugs.python.org/i

[issue45991] Improve ambiguous docstrings in pkgutil

Stanley added the comment: While it is ambiguous, when there's a path parameter I would default it to string unless otherwise specified. Maybe instead a note could be put in the Pathlib doc noting functions that accept path arguments might not accept Path ob

[issue12165] [doc] clarify documentation of nonlocal

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 6.0 -> 7.0 pull_requests: +29672 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31551 ___ Python tracker <https://bugs.python.org/i

[issue30677] [doc] mention that os.mkdir() raises FileNotFound if path does not exist

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 3.0 -> 4.0 pull_requests: +29669 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31548 ___ Python tracker <https://bugs.python.org/i

[issue45991] Improve ambiguous docstrings in pkgutil

Stanley added the comment: Could you expand a bit on why 'list of paths' in pkgutil is understood by default to be 'list of PosixPath paths'? I would interpret it by default to be string paths if I saw it somewhere without context -

[issue34429] [doc] On Windows tempfile.TemporaryFile behaves like NamedTemporaryFile

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 4.0 -> 5.0 pull_requests: +29668 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31547 ___ Python tracker <https://bugs.python.org/i

[issue23747] [doc] platform module exposes win32_ver function on posix systems

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 4.0 -> 5.0 pull_requests: +29591 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31462 ___ Python tracker <https://bugs.python.org/i

[issue31327] [doc] Add example of platform-specific support for negative timestamps to the time doc

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 8.0 -> 9.0 pull_requests: +29589 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31460 ___ Python tracker <https://bugs.python.org/i

[issue36557] [doc] Clarify the meaning of /uninstall in windows cli

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 7.0 -> 8.0 pull_requests: +29586 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31457 ___ Python tracker <https://bugs.python.org/i

[issue45492] stdlib inspect documentation on code.co_names is incorrect

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 2.0 -> 3.0 pull_requests: +29585 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31456 ___ Python tracker <https://bugs.python.org/i

[issue21910] [doc] File protocol should document if writelines must handle generators sensibly

Change by Stanley : -- keywords: +patch pull_requests: +29414 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31245 ___ Python tracker <https://bugs.python.org/issu

[issue21910] [doc] File protocol should document if writelines must handle generators sensibly

Stanley added the comment: I'd be interested in taking a look at this - would these changes clarify things? Current (https://docs.python.org/3/library/codecs.html#codecs.StreamWriter): Writes the concatenated list of strings to the stream (possibly by reusing the write() method)

[issue44697] Memory leak when asyncio.open_connection raise

Kyle Stanley added the comment: Thank you Arteem, that should help indicate where the memory leak is present. -- ___ Python tracker <https://bugs.python.org/issue44

[issue39529] Deprecate get_event_loop()

Kyle Stanley added the comment: > But why does `asyncio.run` unconditionally create a new event loop instead of > running on `asyncio.get_event_loop`? AFAIK, it does so for purposes of compatibility in programs that need multiple separate event loops and providing a degree o

[issue39995] test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno 9] Bad file descriptor

Kyle Stanley added the comment: Thanks for closing up the issue, Victor :) -- ___ Python tracker <https://bugs.python.org/issue39995> ___ ___ Python-bugs-list m

[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port

Kyle Stanley added the comment: > Thanks, Ned <3 (For following up and closing the issue) -- ___ Python tracker <https://bugs.python.org/issue37228> ___ __

[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port

Kyle Stanley added the comment: > Since 3.5 has now reached end-of-life, this issue will not be fixed there so > it looks like it can be closed. Thanks, Ned <3 -- ___ Python tracker <https://bugs.python.or

[issue42647] Unable to use concurrent.futures in atexit hook

Kyle Stanley added the comment: Thanks for bringing attention to this, Julien. While the regression is definitely unfortunate, I'm uncertain about whether the behavior is *correct* to allow in the first place. Specifically, allowing the registration of an atexit hook which u

[issue41962] Make threading._register_atexit public?

Kyle Stanley added the comment: > I'm dealing with a subtle deadlock involving > concurrent.futures.ThreadPoolExecutor, and my solution that worked in Python > 3.8 broke with 3.9. I'm running some long-running (possibly infinite) tasks > in the thread pool, and I can

[issue42611] PEP 594

New submission from Kyle Stanley : This issue was created for the purpose of tracking any changes related to PEP 594 (Removing dead batteries from stdlib), and any relevant discussions about the modules being removed. -- components: Library (Lib) messages: 382815 nosy: aeros

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Kyle Stanley added the comment: New changeset b9127dd6eedd693cfd716a648864e2e00186 by Yurii Karabas in branch 'master': bpo-42392: Improve removal of *loop* parameter in asyncio primitives (GH-23499) https://github.com/python/cpython/commit/b9127dd6eedd693cfd716a6488

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Kyle Stanley added the comment: > Is there anyone who is assigned to removing the deprecated `loop` parameter > from `asyncio` codebase? > If not I can take this task, I believe I have enough free time and curiosity > to do that :) You can certainly feel free to work on that

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Kyle Stanley added the comment: Regarding the example _get_loop(): ``` def _get_loop(self): loop = asyncio.get_running_loop() if self._loop is None: self._loop = loop if loop is not self._loop: raise if not loop.is_running

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Kyle Stanley added the comment: > Oh my. FWIW I think that we need to implement this differently. I don't > think it matters where, say, an asyncio.Lock was instantiated. It can be > created anywhere. So IMO its __init__ shouldn't try to capture the current > loop

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Kyle Stanley added the comment: Sure, I would be interested in helping with this. Although if a newer contributor takes it up before I'm able to, I wouldn't be opposed to that either (my main priority at the moment is helping with PEP 594 since it's a concrete goal of my in

[issue41699] Potential memory leak with asyncio and run_in_executor

Kyle Stanley added the comment: > Regularly calling executor.shutdown() and then instantiating a new > ThreadPoolExecutor in order to run an asyncio program does not seem like a > good API to me. Clarification: you're typically only supposed to instantiate a single ThreadP

[issue41699] Potential memory leak with asyncio and run_in_executor

Kyle Stanley added the comment: Also note that the difference in memory is much higher when an exception occurs (presumably because the exception is stored on future._exception and not cleaned up?): ``` [aeros:~/repos/cpython]$ ./python ~/programming/python/asyncio_run_in_exec_leak.py -n

[issue41699] Potential memory leak with asyncio and run_in_executor

Kyle Stanley added the comment: In the snippet provided, at least part of the resources are not finalized because executor.shutdown() was not called in the program (which should be done when creating a local instance of the executors, either explicitly or using the context manager). For the

[issue41588] Potential Memory leak with concurrent.futures.ThreadPoolExecutor's map

Change by Kyle Stanley : -- nosy: +aeros, bquinlan, pitrou ___ Python tracker <https://bugs.python.org/issue41588> ___ ___ Python-bugs-list mailing list Unsub

[issue28533] Replace asyncore

Kyle Stanley added the comment: Since this issue is now a significant blocker for PEP 594 (remove stdlib dead batteries, which includes asyncore and asynchat), I'm going to prioritize working on this and assign it to myself. -- assignee: -&g

[issue38912] test_asyncio altered the execution environment

Kyle Stanley added the comment: I've applied Justin's patch, and opened PRs for backporting to 3.9 and 3.8 (currently waiting on CI). Based on my local testing and buildbot fleet results, it definitely reduces the rate at which the failure occurs, but does not 100% resolve the E

[issue38912] test_asyncio altered the execution environment

Kyle Stanley added the comment: New changeset de73d432bb29f6439f2db16cb991e15e09c70c26 by Justin Turner Arthur in branch 'master': bpo-38912: fix close before connect callback in test_asyncio SSL tests (GH-22691) https://github.com/python/cpyt

[issue29127] Incorrect reference names in asyncio.subprocess documentation

Kyle Stanley added the comment: I can confirm that both on the latest version of the docs (for 3.8) and for the version mentioned in the issue (3.6), the issue mentioned with asyncio.subprocess.PIPE is no longer present. (It was likely fixed in the asyncio documentation overhaul that

[issue37294] concurrent.futures.ProcessPoolExecutor state=finished raised error

Kyle Stanley added the comment: DanilZ, could you take a look at the superseding issue (https://bugs.python.org/issue37297) and see if your exception raised within the job is the same? If it's not, I would suggest opening a separate issue (and linking to it in a comment here), as I

[issue41815] SQLite: segfault if backup called on closed database

Kyle Stanley added the comment: I've received approval from Lukasz to backport to 3.9 and 3.8, and have now merged the PRs. It could use a post-commit review from a core dev that has some additional experience with SQLite3, but it can be de-escalated from release bl

[issue41815] SQLite: segfault if backup called on closed database

Change by Kyle Stanley : -- nosy: +ghaering ___ Python tracker <https://bugs.python.org/issue41815> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41815] SQLite: segfault if backup called on closed database

Kyle Stanley added the comment: With this being a segfault that's simple to replicate under normal circumstances, I've elevated the priority to release blocker. I'll wait on the release manager (Lukasz) for explicit approval for backporting to 3.9 and 3.8, with both branch

[issue41818] Lib/pty.py major revision

Kyle Stanley added the comment: In addition to the above, if a major revision is made to pty, I'd suggest also addressing the issue of "master/slave" terminology, and replace it with something comparable like "parent/child". There's an open devguide issue (http

[issue39349] Add "cancel_futures" parameter to concurrent.futures.Executor.shutdown()

Kyle Stanley added the comment: Thanks for bringing attention to cancel_futures being missing in the base Executor class and for the PR, Shantanu! -- ___ Python tracker <https://bugs.python.org/issue39

[issue39349] Add "cancel_futures" parameter to concurrent.futures.Executor.shutdown()

Kyle Stanley added the comment: New changeset a763ee3c583e6a2dfe1b1ac0600a48e8a978ed50 by Shantanu in branch '3.9': [3.9] bpo-39349: Add cancel_futures to Executor.shutdown base class (GH-22023) (GH-22048) https://github.com/python/cpython/commit/a763ee3c583e6a2dfe1b1ac0600a48

[issue39349] Add "cancel_futures" parameter to concurrent.futures.Executor.shutdown()

Kyle Stanley added the comment: New changeset 17dc1b789ecc33b4a254eb3b799085f4b3624ca5 by Shantanu in branch 'master': bpo-39349: Add cancel_futures to Executor.shutdown base class (GH-22023) https://github.com/python/cpython/commit/17dc1b789ecc33b4a254eb3b799085

[issue41682] test_asyncio: Proactor test_sendfile_close_peer_in_the_middle_of_receiving failure

Change by Kyle Stanley : -- nosy: -paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker <https://bugs.python.org/issue41682> ___ ___ Python-bug

[issue41682] test_asyncio: Proactor test_sendfile_close_peer_in_the_middle_of_receiving failure

Change by Kyle Stanley : -- components: +Windows, asyncio nosy: +paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker <https://bugs.python.org/issue41

[issue41682] test_asyncio: Proactor test_sendfile_close_peer_in_the_middle_of_receiving failure

Kyle Stanley added the comment: In case the link to the logs are lost from closing and reopening the PR, it was a Windows CI test (GitHub actions) ran with the following configuration: D:\a\cpython\cpython>"D:\a\cpython\cpython\PCbuild\amd64\python.exe" -u -Wd -E -bb -m test

[issue41682] test_asyncio: Proactor test_sendfile_close_peer_in_the_middle_of_receiving failure

Change by Kyle Stanley : -- components: +Tests nosy: +asvetlov, yselivanov type: -> behavior versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issu

[issue41682] test_asyncio: Proactor test_sendfile_close_peer_in_the_middle_of_receiving failure

New submission from Kyle Stanley : In an unrelated PR to add a new argument to the base Executor class for concurrent.futures, there was a test_asyncio failure in test_sendfile for the ProactorEventLoop tests: == FAIL

[issue41682] test_asyncio: Proactor

Change by Kyle Stanley : -- nosy: aeros priority: normal severity: normal status: open title: test_asyncio: Proactor ___ Python tracker <https://bugs.python.org/issue41

[issue39349] Add "cancel_futures" parameter to concurrent.futures.Executor.shutdown()

Kyle Stanley added the comment: Good catch, Shantanu. It was not intentional on my part, and it would make sense to include *cancel_futures* in the base Executor class as documented. If you'd like to submit a PR to add it (attaching it to this issue), I should be able to review it wit

[issue41577] Cannot use ProcessPoolExecutor if in a decorator?

Kyle Stanley added the comment: Due to the way pickle works, it's not presently possible to serialize wrapped functions directly, at least not in a way that allows you to pass it to executor.submit() within the inner function (AFAICT). I'm also not certain what it would involve

[issue41202] Allow to provide custom exception handler to asyncio.run()

Kyle Stanley added the comment: > Should I set status for this issue for closed with resolution rejected ? I'll proceed with closing the issue. > Should I delete branch on my forked git repo ? > Can I delete my forked git repo ? Might as well delete the branch, but the forked

[issue41202] Allow to provide custom exception handler to asyncio.run()

Kyle Stanley added the comment: Yep, having to set a custom exception handler definitely constitutes as needing "finer control over the event loop behavior". There's absolute nothing wrong with using the low-level API when you need further customization, but we try to mi

[issue40967] asyncio.Task.all_tasks() and asyncio.Task.current_task() must be removed in 3.9

Kyle Stanley added the comment: Thanks Rémi for working on this. -- priority: release blocker -> normal stage: patch review -> commit review ___ Python tracker <https://bugs.python.org/i

[issue40967] asyncio.Task.all_tasks() and asyncio.Task.current_task() must be removed in 3.9

Kyle Stanley added the comment: > With beta 4 coming in 2 days it would perhaps good to choose now whether this > must be done for 3.9 or 3.10 Agreed. I'm definitely leaning towards 3.10 with it being decently well into the beta, but I'll try to bring this to Yury'

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Kyle Stanley added the comment: Thanks again for working on this @Fantix, and for the continued vigilance on the issue after the test failures occurred in the buildbots. I think this recent PR-20868 will do the trick. At the very least, it will make the failure much more rare than before

[issue40973] platform.platform() in Python 3.8 does not report detailed Linux platform information

Change by Kyle Stanley : -- nosy: +aeros ___ Python tracker <https://bugs.python.org/issue40973> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40973] platform.platform() in Python 3.8 does not report detailed Linux platform information

Change by Kyle Stanley : -- nosy: +jaraco, lemburg ___ Python tracker <https://bugs.python.org/issue40973> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Kyle Stanley added the comment: > Last question before PR pls: given the fact that this test is to cover a > fixed case when loop.sock_*() was hanging forever, should I keep the > wait_for(..., timeout=10)? For now, I think we can keep the asyncio.wait_for() w/ 10 the sec time

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Kyle Stanley added the comment: No problem at all, and thanks for clarifying. > If enlarging the timeout works in some of your cases, that really inspires me > on a potential cause of the issue in the test. To simulate the race condition > specifically for loop.sock_sendall(), I

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Kyle Stanley added the comment: I believe that I might have identified a simple fix for the issue, but first I'd like to clarify on something: What exactly is the reason that we need to use asyncio.wait_for() with a timeout of 10 seconds in these tests? We typically avoid using

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Kyle Stanley added the comment: I was able to replicate the failure locally by running the large number of jobs in parallel. We typically use this to test for tricky race conditions, to simulate maximum load: [aeros:~/repos/cpython]$ ./python -m test test_asyncio.test_sock_lowlevel --match

[issue40967] asyncio.Task.all_tasks() and asyncio.Task.current_task() must be removed in 3.9

Kyle Stanley added the comment: Thanks for bringing attention to this Rémi. I'm a bit concerned that it might be a bit late into the 3.9 beta to incorporate a removal and that we might need to consider delaying to 3.10, but I'll leave that up to Lukasz. Feel free to open a

[issue40894] asyncio.gather() cancelled() always False

Kyle Stanley added the comment: Thanks for the additional feedback, Caleb. > I think `gather()` should work the same. It would be confusing if > `future_gather.cancelled()` is false if a child is cancelled, while a plain > old outer future returns `future.cancelled() == true` i

[issue40894] asyncio.gather() cancelled() always False

Kyle Stanley added the comment: Upon further investigation, I've realized that the issue is just that the cancel() override for `_GatheringFuture` never sets its state to CANCELLED at any point (unlike its parent), and is instead going to always be set to FINISHED because o

[issue40894] asyncio.gather() cancelled() always False

Kyle Stanley added the comment: > So, we can't rely on checking ``self.done() and self._cancel_requested`` for > future.cancelled() as this would mean that future.cancelled() would return > true for a future that fully completed if `future.cancel()` was called after > it f

[issue40894] asyncio.gather() cancelled() always False

Kyle Stanley added the comment: > Specifically a future can't be cancelled once it reaches the PENDING state, > this is indicated when future.cancel() returns false; see > https://github.com/python/cpython/blob/0e96c419d7287c3c7f155c9f2de3c61020386256/Lib/asyncio/futures.py#L

[issue40894] asyncio.gather() cancelled() always False

Kyle Stanley added the comment: Thank you for the bug report Timm. While I can certainly understand the source of the confusion here, I think you may be misunderstanding an important part of cancellation for futures. Specifically a future can't be cancelled once it reaches the PENDING

[issue40802] AbstractEventLoop.shutdown_default_executor breaks backwards compatibility

Kyle Stanley added the comment: The main issue is that shutdown_default_executor() (or something that does the same thing) is necessary to ensure the resources of the event loop's ThreadPoolExecutor are finalized in a safe manner. Otherwise, it frequently results in dangling threads

[issue40061] Possible refleak in _asynciomodule.c future_add_done_callback()

Kyle Stanley added the comment: Thanks for the PR, Zackery. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue35621] asyncio.create_subprocess_exec() only works with main event loop

Kyle Stanley added the comment: > is there a workaround for earlier Python versions that does not involve > patching the standard library? You could potentially try using the new default watcher, `ThreadedChildWatcher`, by implementing it locally and setting it as the child watcher

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Kyle Stanley added the comment: > The new test_sock_client_racing() test seems to have... a race condition... I'm also a bit skeptical about relying on `time.sleep(0.01)` at the end of the loop in `_basetest_sock_recv_racing()`, but I don't have an idea for a better approach

[issue40782] AbstactEventLoop.run_in_executor is listed as an async method, but should actually return a Futrue

Kyle Stanley added the comment: >From looking at the commit history of AbstactEventLoop.run_in_executor(), it >seems that it was previously be a non-coroutine method prior to the conversion >from the `@asyncio.coroutine` decorator to `async def` (PR-4753). See >https://githu

[issue40160] documentation example of os.walk should be less destructive

Kyle Stanley added the comment: > I made the suggested change to just print the os.remove() statements (instead > of executing them) and also removed the 'skip news'. I think you may have misunderstood the suggestion. Specifically, the key part was "I would suggest add

[issue40405] asyncio.as_completed documentation misleading

Kyle Stanley added the comment: Thanks for bring this to our attention and working on this Bar Harel, and thanks to Yury for the suggestions. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Pytho

[issue40405] asyncio.as_completed documentation misleading

Kyle Stanley added the comment: New changeset 13206b52d16c2489f4c7dd2dce2a7f48a554b5ed by Bar Harel in branch 'master': bpo-40405: Fix asyncio.as_completed docs (GH-19753) https://github.com/python/cpython/commit/13206b52d16c2489f4c7dd2dce2a7f

  1   2   3   4   5   >