Kyle Evans added the comment:
Sure, sounds good to me. The original theory (IIRC, I've slept many times since
then :-)) was that we already know first/last are valid and there are no other
defined errors, so 'other errors' must be because close_range has started
percolati
Change by Kyle Smith :
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue46871>
___
___
Python-bugs-list mailing list
Unsubscrib
Kyle Smith added the comment:
I think that's fair, thanks for the conversation at least. I understand python
mp a little bit more now...
--
status: pending -> open
___
Python tracker
<https://bugs.python.org
Change by Kyle Smith :
--
title: BaseManager.register no longer supports lambda callable 3.8.12+ ->
Lambda can't be pickled with "spawn" and only "fork"
___
Python tracker
<htt
Kyle Smith added the comment:
Since you were able to help me scope that this is probably an MacOS specific
issue, I was able to find this report:
https://github.com/pytest-dev/pytest-flask/issues/104
Setting `multiprocessing.set_start_method("fork")` _BEFORE_ the code is called
Kyle Smith added the comment:
Interesting. I did try between MacOS (12.2) and Ubuntu since I have servers
with older python versions. For scoping then, this appears to be related only
to MacOS since you were able to confirm it working correctly on Linux.
The code is the same, but here&#
New submission from Kyle Smith :
The below code works on versions 3.5.2 to 3.8.10. Higher versions tested, such
as 3.9.12 and 3.10.2 result in the error:
"AttributeError: Can't pickle local object".
from multiprocessing import Lock
from multiprocessing.managers impor
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
Change by Kyle Altendorf :
--
nosy: +altendky
___
Python tracker
<https://bugs.python.org/issue32219>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Kyle Stanley added the comment:
Thanks for closing up the issue, Victor :)
--
___
Python tracker
<https://bugs.python.org/issue39995>
___
___
Python-bugs-list m
Kyle Stanley added the comment:
> Thanks, Ned <3
(For following up and closing the issue)
--
___
Python tracker
<https://bugs.python.org/issue37228>
___
__
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
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
Kyle Altendorf added the comment:
I'm not sure why I got added... but as mentioned in the SO response, this
isn't how stuff works. Python isn't monitoring what subprocesses are created
in the tree below the one Python itself creates nor does it have any way to
know whic
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
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
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
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
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
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
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
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
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
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
Change by Kyle Stanley :
--
nosy: +aeros, bquinlan, pitrou
___
Python tracker
<https://bugs.python.org/issue41588>
___
___
Python-bugs-list mailing list
Unsub
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
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
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
Change by Kyle Evans :
--
pull_requests: +21651
pull_request: https://github.com/python/cpython/pull/22680
___
Python tracker
<https://bugs.python.org/issue40
Change by Kyle Evans :
--
pull_requests: +21646
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/22672
___
Python tracker
<https://bugs.python.org/issu
Kyle Evans added the comment:
Excellent, thank you.
--
___
Python tracker
<https://bugs.python.org/issue40422>
___
___
Python-bugs-list mailing list
Unsub
Kyle Evans added the comment:
Would you like that on a distinct issue, or is it ok to reuse this BPO since
it's a location improvement of an API just introduced?
I've got a local branch now that:
1. moves the suppress IPH stuff into _Py_closerange
2. moves the definition i
Change by Kyle Evans :
--
nosy: +kevans
nosy_count: 8.0 -> 9.0
pull_requests: +21629
pull_request: https://github.com/python/cpython/pull/22651
___
Python tracker
<https://bugs.python.org/issu
Change by Kyle Evans :
--
nosy: +kevans
nosy_count: 28.0 -> 29.0
pull_requests: +21627
pull_request: https://github.com/python/cpython/pull/22651
___
Python tracker
<https://bugs.python.org/iss
Change by Kyle Evans :
--
nosy: +kevans
nosy_count: 8.0 -> 9.0
pull_requests: +21628
pull_request: https://github.com/python/cpython/pull/22651
___
Python tracker
<https://bugs.python.org/issu
Change by Kyle Evans :
--
pull_requests: +21624
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22651
___
Python tracker
<https://bugs.python.org/issu
Kyle Evans added the comment:
Ah, I will fix this and then submit a PR, thanks... hopefully it returns ENOSYS.
--
nosy: +kevans
___
Python tracker
<https://bugs.python.org/issue40
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
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
Change by Kyle Altendorf :
--
nosy: +altendky
___
Python tracker
<https://bugs.python.org/issue38989>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kyle Altendorf :
--
nosy: +altendky
___
Python tracker
<https://bugs.python.org/issue25655>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kyle Altendorf :
--
nosy: +altendky
___
Python tracker
<https://bugs.python.org/issue41836>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Change by Kyle Stanley :
--
nosy: +ghaering
___
Python tracker
<https://bugs.python.org/issue41815>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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
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
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
Change by Kyle Stanley :
--
nosy: -paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<https://bugs.python.org/issue41682>
___
___
Python-bug
Change by Kyle Stanley :
--
components: +Windows, asyncio
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<https://bugs.python.org/issue41
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
Change by Kyle Stanley :
--
components: +Tests
nosy: +asvetlov, yselivanov
type: -> behavior
versions: +Python 3.10
___
Python tracker
<https://bugs.python.org/issu
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
Change by Kyle Stanley :
--
nosy: aeros
priority: normal
severity: normal
status: open
title: test_asyncio: Proactor
___
Python tracker
<https://bugs.python.org/issue41
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
Kyle Meyer added the comment:
I should have thought to provide the output of when debug=True is
passed to asyncio.run(). Here it is, with the python on my Debian
system:
$ python3 -V
Python 3.7.3
$ python3 reproducer.py
Iteration: 1 of 100
Failed on iteration 1
Kyle Mulka added the comment:
Was able to reproduce with Python 3.9.0rc1 using issue38884.zip. macOS 10.15.5
--
___
Python tracker
<https://bugs.python.org/issue38
Change by Kyle Mulka :
--
nosy: +repalviglator
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue38884>
___
___
Python-bugs-list mailin
New submission from Kyle Meyer :
I've been debugging an intermittent test failure in code that calls
`loop.subprocess_exec` with an `asyncio.SubprocessProtocol` subclass.
Here's a minimal example that I hope captures the issue. It's based
closely off of the `DateProtocol` [exa
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
Kyle Evans added the comment:
Hey koobs,
Can you confirm that this is fine now after I implemented SHM_GROW_ON_WRITE?
--
___
Python tracker
<https://bugs.python.org/issue41
Kyle Evans added the comment:
I can confirm that neither 12 nor 11 will be getting memfd_create; file sealing
is a little more complicated to MFC, and I don't want to provide memfd_create
in a place where it can't be paired with file sealing in case applications
assume they co
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
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
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
Kyle Evans added the comment:
Ah, sorry, I meant to update this- I submitted our fix for review a day or two
ago, got approval for commit and will poke koobs to rebuild the FreeBSD
-CURRENT buildbot with it after that.
--
___
Python tracker
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'
Kyle Evans added the comment:
Ah, now that I'm more awake, I see the problem- the write is unsuccessful
because I haven't yet implemented grow-on-write. None of the consumers that I
had found relied on it, instead choosing to ftruncate() it to the size they
need before operating
Kyle Evans added the comment:
(Transcription error beyond the bogus os.exit() :-))
--
___
Python tracker
<https://bugs.python.org/issue41013>
___
___
Python-bug
Kyle Evans added the comment:
I think it's too early to look at this, I'll circle back another time. :-) I
got a minute and extracted the relevant test, but I guess there must have been
some fundamental transcription error:
import os
fd = os.memfd_create("Hi", os.MFD_
Kyle Evans added the comment:
Interesting; I don't quite have time to look at the moment, but what is the
test doing that it's ultimately timing out?
Our memfd_create is assumed to be compatible, with the exception that we don't
yet support HUGETLB (but there are patches in p
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
Change by Kyle Stanley :
--
nosy: +aeros
___
Python tracker
<https://bugs.python.org/issue40973>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kyle Stanley :
--
nosy: +jaraco, lemburg
___
Python tracker
<https://bugs.python.org/issue40973>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Kyle Stanley added the comment:
Now that the `versionadded` label has been added and the contextvar issue was
addressed, this issue can be closed.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Pytho
Change by Kyle Stanley :
--
pull_requests: +19555
pull_request: https://github.com/python/cpython/pull/20278
___
Python tracker
<https://bugs.python.org/issue32
Change by Kyle Stanley :
--
pull_requests: +19448
pull_request: https://github.com/python/cpython/pull/20143
___
Python tracker
<https://bugs.python.org/issue32
Kyle Stanley added the comment:
> Would it make sense to deprecate it and stick with ThreadedChildWatcher?
I had proposed deprecating it in another bpo issue, but it was brought up that
MutliLoopWatcher had only been added recently in 3.8. So, it might be a bit too
soon to deprecate
Change by Kyle Stanley :
--
pull_requests: +19324
pull_request: https://github.com/python/cpython/pull/20013
___
Python tracker
<https://bugs.python.org/issue38
Kyle Stanley added the comment:
> What other MultiLoopWatcher tests are currently having random hangs?
Oh, never mind. I see `test_stdin_stdout` is also hanging in
https://bugs.python.org/issue38182. I would like to take a closer look at that
one before skipping it as w
1 - 100 of 533 matches
Mail list logo
