Change by Kyle Stanley :
--
keywords: +patch
pull_requests: +17451
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18057
___
Python tracker
<https://bugs.python.org/issu
Change by Kyle Stanley :
--
pull_requests: +17452
pull_request: https://github.com/python/cpython/pull/18058
___
Python tracker
<https://bugs.python.org/issue37
Kyle Stanley added the comment:
> So, I just had an interesting idea... what if ThreadPool.run() returned a
> Task instead of a coroutine object?
After having some time to think this over, I prefer the current behavior. I
don't think there would be significant enough impro
Kyle Stanley added the comment:
> The exception should probably be just ignored.
It looks like the "ERROR_NETNAME_DELETED" (win32 error 64) exception is already
ignored in multiprocessing's connection.wait():
https://github.com/python/cpython/blob/bccacd19fa7b56dcf2fbfa
Change by Kyle Stanley :
--
keywords: +patch
pull_requests: +17577
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18199
___
Python tracker
<https://bugs.python.org/issu
Kyle Stanley added the comment:
> Thank you very muck, Kyle!
No problem. Thanks for reviewing and merging the PR, Antoine!
--
___
Python tracker
<https://bugs.python.org/issu
Kyle Stanley added the comment:
In GH-18228, an unrelated failure in test_concurrent_futures occurred (same as
the one above):
Ran 354 tests in 496.802s
OK (skipped=35)
Warning -- files was modified by test_multiprocessing_spawn
Before: []
After: ['python.core']
Full
Kyle Stanley added the comment:
> Thanks, Kyle. That helps at least a little. :)
No problem. (:
I'll certainly spend some additional time investigating the main issue when I
have the chance to, but in the meantime that test change should make it
slightly easier to determine the
Change by Kyle Stanley :
--
pull_requests: +17784
pull_request: https://github.com/python/cpython/pull/18410
___
Python tracker
<https://bugs.python.org/issue32
New submission from Kyle Stanley :
Based on the following python-ideas thread:
https://mail.python.org/archives/list/python-id...@python.org/thread/LMTQ2AI6A7UXEFVHRGHKWD33H24FGM6G/#ICJKHZ4BPIUMOPIT2TDTBIW2EH4CPNCP.
In the above ML thread, the author proposed adding a new cf.SerialExecutor
Kyle Stanley added the comment:
So, essentially, are you looking for a way to dynamically adjust
ProcessPoolExecutor's (PPE) max_workers, rather than just upon initialization?
This seems like it would be a very reasonable enhancement to the Executor API.
Specifically for PPE, it
Change by Kyle Stanley :
--
nosy: +bquinlan, pitrou
___
Python tracker
<https://bugs.python.org/issue39617>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kyle Stanley added the comment:
> Can this issue be closed, I see it was merged successfully?
Yep, I'll go ahead and close the issue now. Thanks for the reminder; I got
caught up in a few other projects.
--
stage: patch review -> resolved
status: ope
Kyle Stanley added the comment:
Upon further consideration and based on recent developments in the python-ideas
thread (mostly feedback from Antoine), I've decided to reduce the scope of this
issue to remove future.set_state() and the *sync* parameters.
This leaves just future.state(
Kyle Stanley added the comment:
Justin Capella wrote:
> Is there a better forum for discussion about design/behavior, maybe the more
> generic issue of GenericPyCData_new using tp_alloc instead of tp_new
Rebecca Morgan wrote:
> I would still be interested in this, with some clari
Kyle Stanley added the comment:
>From what I can tell, the regression seems like it could be fixed by adding
>"@unittest.skipIf(sys.flags.ignore_environment)" to the following tests in
>python/cpython/Lib/test/test_importlib/source/test_case_sensitivity.py that
&g
Kyle Stanley added the comment:
FWIW, I agree with get_event_loop() being problematic with its error messages,
and having a bit too much functionality in a single function from an API design
perspective. It commonly comes up as an issue among asyncio users in
communities that I'm acti
Kyle Stanley added the comment:
> The daemon thread itself is not problematic, because ProcessPoolExecutor uses
> an atexit hook to shutdown itself and therefore join the management thread.
ThreadPoolExecutor also uses an atexit hook for its shutdown process. Also, it
sets each
Kyle Stanley added the comment:
> To me, yes.
If Victor is also on-board with the idea, I can look into writing a patch for
it (after testing to verify that it allows us to change the daemon threads to
normal threads in concurrent.futures without iss
Kyle Stanley added the comment:
+1, I've always found the "too many values to unpack" error messages be rather
vague. Adding the type should make the message more clear, and easier to debug
the error for users.
But, I think Chris Angelico raised a good point regarding the
Kyle Stanley added the comment:
> This leaves just future.state() and having the states as publicly accessible
> module-level constants.
After reading over the python-ideas again and having some time to reflect, I
think we can start with just adding future.state(), as that had th
Kyle Stanley added the comment:
> I’m a bit disappointed, since it looks like this won’t allow implementing the
> OP’s classes without using private APIs. The debugging and loggin use cases
> aren’t very compelling to me.
Yeah, I had every intention when I initially proposed the id
Kyle Stanley added the comment:
> But note my response to Antoine at the time, mentioning that implementing
> ‘as_completed()’ is impossible that way. Antoine then backtracked somewhat.
Ah, I had seen that but for some reason hadn't considered that Antoine might
have also changed
Kyle Stanley added the comment:
I spent some further time considering the solution to the problem, and I still
think something like a `threading.register_atexit()` (see
https://bugs.python.org/issue37266#msg362960) would be the most suitable.
However, I'm not certain regarding the
Change by Kyle Stanley :
--
assignee: -> aeros
___
Python tracker
<https://bugs.python.org/issue39812>
___
___
Python-bugs-list mailing list
Unsubscrib
Kyle Stanley added the comment:
I have a few spare cycles to take another stab at this issue. I can say with
some certainty that the failure in test__xxsubinterpreters.DestroyTests does
not occur on the latest commit to master (3.9):
```
$ ./python -m test test__xxsubinterpreters --match
Kyle Stanley added the comment:
> Is this open for a PR?
I opened a PR for this issue a bit ago (applies Yury's suggestion of
suppressing the exception), just waiting on review from Andrew when he finds
the time to do so.
--
___
Python
Kyle Stanley added the comment:
> only build PRs that have been tagged "documentation"
My preference would be to have a "preview-with-netlify" label that could be
manually added to use the netlify preview on a case-by-case basis. There are a
substantial number of tr
New submission from Kyle Stanley :
In a recent python-ideas thread, the rule of dunder methods being reserved for
Python internal usage only was brought up
(https://mail.python.org/archives/list/python-id...@python.org/message/GMRPSSQW3SXNCP4WU7SYDINL67M2WLQI/),
due to an author of a third
Change by Kyle Stanley :
--
priority: normal -> low
___
Python tracker
<https://bugs.python.org/issue40045>
___
___
Python-bugs-list mailing list
Unsubscrib
Kyle Stanley added the comment:
> I vote for #2. It improves findability while also recognizing that "dunder"
> isn't a formal term and lies somewhere between slang and jargon.
Yeah, I suppose it is a bit more of a slang or jargon term rather than
something with a for
Change by Kyle Stanley :
--
keywords: +patch
pull_requests: +18510
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19149
___
Python tracker
<https://bugs.python.org/issu
New submission from Kyle Stanley :
When using the `test-with-buildbots` label in GH-19149 (which involved no C
changes), a failure occurred in test_asyncio for several of the refleak
buildbots. Here's the output of a few:
AMD64 Fedora Stable Refleaks PR:
test_asyncio leaked [3,
Kyle Stanley added the comment:
> When using the `test-with-buildbots` label in GH-19149 (which involved no C
> changes), a failure occurred in test_asyncio for several of the refleak
> buildbots.
To clarify, the refleak failures occurred when i applied the label to the
followi
Kyle Stanley added the comment:
So, I think a potential approach to this issue with ProcessPoolExecutor would
be making it a bit more similar to ThreadPoolExecutor: instead of spawning
*max_workers* processes on startup (see `_adjust_process_count()`), spawn each
new process in submit
Kyle Stanley added the comment:
> This change introduced a leak in test_asyncio: bpo-40115.
Thanks for bringing attention to it Victor. It seems like a rather odd side
effect, considering that PR-19149 had no C code and was internal to
concurrent.futures and threading. I did not exp
Kyle Stanley added the comment:
I'm currently busy today, but I'll have some time to explore a few different
potential solutions tomorrow. If I can't find anything to fix it by the end of
the day, I'll prepare a PR to revert PR-19149, and re-apply it later (after
more t
Kyle Stanley added the comment:
Currently working on addressing this, see bpo-39812. If I can't find a fix by
tonight, I'll open a PR to revert it for now so that other regressions don't go
undetected in the meantime.
--
nosy: +aeros
___
Kyle Stanley added the comment:
I was able to find a fix! Specifically, I think the issue was a subtle problem
with test_run_in_executor_cancel: it never properly shuts down the executor
prior to closing the event loop.
We do this in asyncio.run() (with the loop.shutdown_default_executor
Change by Kyle Stanley :
--
keywords: +patch
pull_requests: +18639
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19282
___
Python tracker
<https://bugs.python.org/issu
Kyle Stanley added the comment:
I attached a PR to bpo-40115 to address the refleak in test_asyncio: PR-19282.
--
___
Python tracker
<https://bugs.python.org/issue39
Change by Kyle Stanley :
--
nosy: +aeros
nosy_count: 3.0 -> 4.0
pull_requests: +18641
pull_request: https://github.com/python/cpython/pull/19282
___
Python tracker
<https://bugs.python.org/issu
Change by Kyle Stanley :
--
pull_requests: -18641
___
Python tracker
<https://bugs.python.org/issue40024>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kyle Stanley added the comment:
(disregard the above, the PR was mistakenly linked from a GitHub bug)
--
___
Python tracker
<https://bugs.python.org/issue40
Kyle Stanley added the comment:
> Thanks Kyle for the test_asyncio fix!
No problem! Thanks for the review. :-)
--
___
Python tracker
<https://bugs.python.org/issu
Kyle Stanley added the comment:
> Do we really want this to be just an assert, or do we want to raise another
> type of exception?
IMO, we should look into converting this into an exception. Mistakenly having a
task await StreamWriter.drain() at the same time as another is c
Kyle Stanley added the comment:
> ZipInfo currently only allow adding entries to zip archives but doesn't have
> the ability to remove entries from them - pretty useful feature.
This public API enhancement seems substantial enough to warrant a python-ideas
ML thread or topic in
Kyle Stanley added the comment:
Serhiy Storchaka wrote:
> I do not think there is clearer example of topdown=False than recursive
> remove.
>
> If you think that this example is destructive, consider how destructive is
> any possible example for shutil.rmtree()!
I concur with
Kyle Stanley added the comment:
Serhiy Storchaka wrote:
> This is a duplicate of issue700858 and issue6818.
It probably would have been better to mention it in issue6818, but IMO, those
issues have been inactive long enough that it's reasonable to re-address the
issue. zipfile i
New submission from Kyle Stanley :
In several recent PRs, test_ctypes.test_load_dll_with_flags is failing for the
Azure Pipelines "Windows PR tests win32" and "Windows PR tests win64" with the
fol
Kyle Stanley added the comment:
Zachary Ware wrote:
> My best guess at the moment is that something changed in the underlying
> Windows image, particularly given the comment above the failing line that
> "insecure load flags should succeed" (though that could easily
Kyle Stanley added the comment:
Steve Dower wrote:
> (FWIW, we build and test a release build, not a debug build, which is why
> we're not looking for sqlite3_d.dll... but perhaps we should be using a debug
> build? That might be slower, but the extra validation is probably
Kyle Stanley added the comment:
Steve Dower wrote:
> It's one sample point, but compare
> https://buildbot.python.org/all/#/builders/129/builds/708 to
> https://github.com/python/cpython/runs/571497886
FWIW, I'd be +1 in favor for using the debug build then. A few additi
Change by Kyle Stanley :
--
keywords: +patch
pull_requests: +18807
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19453
___
Python tracker
<https://bugs.python.org/issu
Kyle Stanley added the comment:
> So if you are going to eliminate daemon threads (even if only in sub
> interpreters at this point), you are going to have to introduce a way to
> register something similar to an atexit callback which would be invoked
> before waiting on non da
Kyle Stanley added the comment:
> I don't think there's much ThreadPoolExecutor can do. If you drop the
> references to the threads, they still exist and they still be waited upon at
> interpreter exit.
>
> The solution is for you to avoid having hanging threads.
Kyle Stanley added the comment:
> ThreadPoolExecutor introduces additional waiting of its own, and it is this
> wait the PR adds an option to disable.
[next post]
> Thanks for the clarification, I didn't know about the change to non-daemon
> threads.
> I still think
Kyle Stanley added the comment:
> Agreed, and that is precisely what I suggested in my previous comment. The
> attached PR already deals with the executor-specific part of the wait, but it
> would be straightforward to have it also affect the executor to create daemon
> thre
Kyle Stanley added the comment:
> Kyle: Can you please add a short sentence there to document the new
> requirement?
Yep, I'll open a PR soon. I'm glad this is coming up now rather than
post-release, thanks for bringing
Change by Kyle Stanley :
--
pull_requests: +18960
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/19634
___
Python tracker
<https://bugs.python.org/issu
Kyle Stanley added the comment:
New changeset 9c82ea7868a1c5ecf88891c627b5c399357eb05e by Kyle Stanley in
branch 'master':
bpo-34037: Add Python API whatsnew for loop.shutdown_default_executor() (#19634)
https://github.com/python/cpython/commit/9c82ea7868a1c5ecf88891c627b5c3
Kyle Stanley added the comment:
PR-19634 should address the primary issue of documenting in the 3.9 whatsnew
that alternative event loops should implement loop.shutdown_default_executor().
For reference, here's the implementation in BaseEventLoop:
https://github.com/python/cpython
Kyle Stanley added the comment:
Victor Stinner wrote:
> Is there someone interested to propose a PR for that?
I would be interested in looking into this, although I'm not entirely certain
either as to how it should be tested at the moment. I'll have to look further
into the
Change by Kyle Stanley :
--
assignee: -> aeros
___
Python tracker
<https://bugs.python.org/issue40364>
___
___
Python-bugs-list mailing list
Unsubscrib
Kyle Stanley added the comment:
New changeset 5aafa548794d23b6d4cafb4fd88289cd0ba2a2a8 by Cajetan Rodrigues in
branch 'master':
bpo-40340: Separate examples more clearly in the programming FAQ (GH-19688)
https://github.com/python/cpython/commit/5aafa548794d23b6d4cafb4fd88289
Change by Kyle Stanley :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Kyle Stanley added the comment:
Rather than starting this out as a bpo issue, I would highly recommend bringing
forth a proposal for this in python-id...@python.org and explaining in as much
detail as possible:
1) How a frozen variation of collection.Counter would benefit your specific use
Kyle Stanley added the comment:
Also, adding Raymond to the nosy list in case he has any specific comments
about a frozen collections.Counter.
--
nosy: +rhettinger
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue40
Change by Kyle Stanley :
--
nosy: +aeros
___
Python tracker
<https://bugs.python.org/issue39995>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kyle Stanley :
--
nosy: +pitrou
___
Python tracker
<https://bugs.python.org/issue39995>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kyle Stanley added the comment:
I can't be certain for the other failures, but I'm currently exploring a
potential solution for addressing the `test_killed_child` failure. To me, it
seems to be a race condition with attempting to call _ThreadWakeup.close()
while there are still b
Kyle Stanley added the comment:
After writing the above out and a bit of further consideration, I think it
might make more sense to wait for the event after setting `self._closed = True`
so that it prevents future wakeup() and clear() calls from reading/writing to
the pipe, while still
Kyle Stanley added the comment:
paul rubin wrote:
> In that case, it works for what it is made for, so it really then is a
> separate question of whether implementing multisets properly is worthwhile.
Indeed, that seems to be the primary question to address. Personally, I don'
Kyle Stanley added the comment:
paul rubin wrote:
> Yeah I think the basic answer to this ticket is "Python doesn't really have
> multisets and a proposal to add them should go somewhere else". Fair
> enough-- consider the request withdrawn from here.
Not necessari
Change by Kyle Stanley :
--
pull_requests: +19072
pull_request: https://github.com/python/cpython/pull/19751
___
Python tracker
<https://bugs.python.org/issue39
Kyle Stanley added the comment:
Antoine Pitrou wrote:
> You're right that a Py_DECREF is missing there. However, it seems unlikely
> that this is triggering the test failure, because `PyList_New(1)` will
> practically never fail in normal conditions (and even making it delibe
Kyle Stanley added the comment:
Oops, it seems that I opened PR-19751 a bit preemptively. When I get the
chance, I'll see if Antoine's implementation can address the failures and do
some comparisons.
--
___
Python track
Kyle Stanley added the comment:
I decided to close PR-19751. Both because it does not correctly address the
race condition (due to an oversight on my part) and it would add substantial
overhead to _ThreadWakeup. Instead, I agree that we should explore a
non-locking solution
Kyle Stanley added the comment:
> I don't think that it's worth it to backport the change to 3.7 and 3.8: in
> Python 3.7 and 3.8, the code is accepted.
> Python 3.7 and 3.8 are not broken, so there is no need to fix them :-)
I think we could very reasonably change `e
Kyle Stanley added the comment:
For addressing the backwards compatibility concern, I think we should just
convert it to a SyntaxWarning for cases like the above to indicate that it's
not really correct syntax, but not harmful enough to justify code breakage. I
think it fits the docum
Kyle Stanley added the comment:
Victor Stinner wrote:
> If you backport the change, please remove the NEWS entry, since it's not a
> SyntaxError in 3.7 and 3.8.
Good point. In that case, I'll do a manual backport of the PR just to 3.8 and
skip the news entry. As mentione
Change by Kyle Stanley :
--
versions: -Python 3.7
___
Python tracker
<https://bugs.python.org/issue40431>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kyle Stanley :
--
pull_requests: +19107
pull_request: https://github.com/python/cpython/pull/19784
___
Python tracker
<https://bugs.python.org/issue40
Kyle Stanley added the comment:
I am a bit concerned about the performance implication of accessing the thread
wakeup through a lock in the call queue, but for now I think it's reasonable to
address the buildbot failure with a locking solution while we try to find a
better one.
I&
Kyle Stanley added the comment:
Also, thanks to Victor for coming up with an interim solution, and for the
feedback from Antoine and Thomas. GH-19760 is a significant improvement from my
initial proposal in GH-19751.
--
___
Python tracker
<ht
Kyle Stanley added the comment:
New changeset cc011b5190b63f0be561ddec38fc4cd9e60cbf6a by Kyle Stanley in
branch '3.8':
[3.8] bpo-40431: Fix syntax typo in turtledemo (GH-19777) (#19784)
https://github.com/python/cpython/commit/cc011b5190b63f0be561ddec38fc4c
Change by Kyle Stanley :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Kyle Stanley added the comment:
Yury Selivanov wrote:
> I'd suggest to change to: "Return an iterator of coroutines. Each coroutine
> allows to wait for the earliest next result from the set of the remaining
> awaitables."
The first sentence looks good to me, but I
Kyle Stanley added the comment:
> based upon the order of completion
I forgot to explain this in the above message. I think something that mentions
"order of completion" should be included. Although it's implied in the name
`as_completed`, to me it seems worthwhile to be f
Kyle Stanley added the comment:
Alternatively, I think "can wait for" would also read better than "allows to
wait for", if that is preferred over my above suggestion.
--
___
Python tracker
<https://bug
Kyle Stanley added the comment:
@Bar as requested by Guido, let's continue the discussion in the PR:
https://github.com/python/cpython/pull/19753#pullrequestreview-403185142.
--
___
Python tracker
<https://bugs.python.org/is
Kyle Stanley added the comment:
John Smith wrote:
> The code works normally again if I remove the return statement from the
> `run_coro` function.
I am a bit surprised that the code works as intended simply by removing the
return statement. Perhaps Yury or Andrew can clarify on that
Change by Kyle Stanley :
--
nosy: +aeros
___
Python tracker
<https://bugs.python.org/issue40512>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kyle Stanley added the comment:
I have also explored a few different solutions and was unable to find a fix for
this issue. If it's still causing intermittent hangs after Andrew's patch, we
may want to consider skipping `test_close_kill_running` for `MultiLoopWatcher`
until we ca
Kyle Stanley added the comment:
> Is the new asyncio.loop.shutdown_default_executor() suitable for event loops
> that are run in single-step mode?
I honestly can't say for certain; the primary intended use case for
shutdown_default_executor() was to provide a means of properly
Kyle Stanley added the comment:
I presume this is referring to the following example on the first page of the
docs:
```
import asyncio
async def main():
print('Hello ...')
await asyncio.sleep(1)
print('... World!')
# Python 3.7+
asyncio.run(main())
```
If
Kyle Stanley added the comment:
> There are more MultiLoopWatcher tests which hang randomly, it's not only
> test_close_kill_running().
What other MultiLoopWatcher tests are currently having random hangs? From
searching "MultiLoopWatcher" on bpo, I'm only finding
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
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:
> 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
201 - 300 of 416 matches
Mail list logo
