Kyle Stanley added the comment:
> Regarding "is_running()", notice that it relies almost entirely on
> "frame->f_executing". That might not be enough (or maybe the behavior there
> changed). That would be worth checking out.
Based on the above hint, I was
Kyle Stanley added the comment:
> so that operations (such as running scripts, destroying the interpreter, etc)
> can't occur during finalization
Clarification: by "destroying the interpreter" I am specifically referring to
calling `interp_destroy()` after finalizatio
Kyle Stanley added the comment:
> Where are we with this? The deadline for 3.8.1 and 3.7.6 is coming up in a
> few days.
I believe we're just waiting on review and additional feedback on GH-17311,
which implements Antoine's proposal. The only remaining component I can
Kyle Stanley added the comment:
Thanks for taking care of merging to 3.x (master) and 3.8, Łukasz!
> Kyle, I'm releasing 3.8.1rc1 now. Please add the What's New entry before next
> Monday (3.8.1).
No problem, I'll definitely have time to do that before 3.8.1 final, li
Kyle Stanley added the comment:
> The backport to 3.7 seems straightforward so I did it to unblock 3.7.6rc1.
> The backport to 3.6 is a bit more complicated and 3.6.10rc1 can wait a bit
> longer so I'll leave that for Kyle along with the various What's New entries.
Kyle Stanley added the comment:
> since the release for 3.7.1 and 3.7.6 are coming up soon.
Clarification: should be "since the release for 3.8.1 and 3.7.6 are coming up
soon", that was a typo.
--
___
Python tracker
<https:/
Kyle Stanley added the comment:
Oh okay, I'll work on the 3.6 backport first then.
--
___
Python tracker
<https://bugs.python.org/issue37228>
___
___
Pytho
Change by Kyle Stanley :
--
pull_requests: +17045
pull_request: https://github.com/python/cpython/pull/17571
___
Python tracker
<https://bugs.python.org/issue37
Kyle Stanley added the comment:
Now that the backports for 3.6-3.8 are merged, I'll work on the What's New
entries next. Waiting on feedback from Larry Hastings regarding the potential
3.5 backport, I'll add him to the nosy list.
Kyle Stanley added the comment:
> The fix seems to generate few DeprecationWarning while running test suite
> with -Wall.
Thanks Karthikeyan, I'm guessing that I missed an assertWarns() or left an
outdated test somewhere that explicitly sets `reuse_address=False` (since
`reuse_a
Kyle Stanley added the comment:
> or left an outdated test somewhere that explicitly sets `reuse_address=False`
Looks like this was the issue, I left a `reuse_address=False` in both
test_create_datagram_endpoint_nosoreuseport and
test_create_datagram_endpoint_ip_addr. I fixed it locally
Kyle Stanley added the comment:
> I'll fix them accordingly and open a new PR (as well as the backports).
Nevermind. Upon further inspection, the other occurrences of `reuse_address=`
were for create_server(), not create_datagram_endpoint(). The PR will only
include the removal of
Kyle Stanley added the comment:
> One more resource warning about unclosed resource being garbage collected. As
> per the other tests I think transport and protocol need to be closed as per
> below patch but someone can verify if it's the right approach.
Ah, good catch. It
Change by Kyle Stanley :
--
pull_requests: +17051
pull_request: https://github.com/python/cpython/pull/17577
___
Python tracker
<https://bugs.python.org/issue37
Kyle Stanley added the comment:
Thanks for letting us know, janust. I confirmed that `asyncio.TimeoutError` no
longer works for the code example in 3.8 and that replacing it with
`concurrent.futures.TimeoutError` works correctly.
Before moving forward with a PR to the docs, I think we
Change by Kyle Stanley :
--
pull_requests: +17067
pull_request: https://github.com/python/cpython/pull/17595
___
Python tracker
<https://bugs.python.org/issue37
Kyle Stanley added the comment:
Opened a PR that adds the whatsnew entries to master, 3.8, 3.7, and 3.6:
GH-17595.
--
___
Python tracker
<https://bugs.python.org/issue37
Kyle Stanley added the comment:
> Yep, it has to use the public C-API just like any other module. The
> function has a "_Py" prefix and be defined in Include/cpython, right?
Yeah, I named it "_PyInterpreterIsFinalizing" and it's within Include/cpython.
Defini
Change by Kyle Stanley :
--
pull_requests: +17099
pull_request: https://github.com/python/cpython/pull/17630
___
Python tracker
<https://bugs.python.org/issue37
Change by Kyle Stanley :
--
pull_requests: +17100
pull_request: https://github.com/python/cpython/pull/17631
___
Python tracker
<https://bugs.python.org/issue37
Change by Kyle Stanley :
--
pull_requests: +17101
pull_request: https://github.com/python/cpython/pull/17632
___
Python tracker
<https://bugs.python.org/issue37
Kyle Stanley added the comment:
Thanks for taking care of merging the remaining backport PRs for 3.6-3.8, Ned.
Now, the only branch left is (potentially) 3.5.
--
___
Python tracker
<https://bugs.python.org/issue37
New submission from Kyle Stanley :
For context, I decided to open this issue after receiving a substantial volume
of very similar questions and misconceptions from users of asyncio and trio
about what `await` does, mostly within a dedicated "async" topical help chat
(in the "
Kyle Stanley added the comment:
> Sorry, my English is bad; I cannot help with docs too much.
No problem. Your feedback is still incredibly helpful and very much appreciated
either way. (:
> Anyway, technically an awaited coroutine *can* be suspended but the
> suspension is n
Kyle Stanley added the comment:
> For a struct-specific getter we usually end the prefix with an
underscore: _PyInterpreter_IsFinalizing. Otherwise, that's the same
name I would have used. :)
Good to know, thanks!
> No worries (or hurries). Just request a review from me when y
Kyle Stanley added the comment:
> What "ignores the max_workers argument" means?
>From my understanding, their argument was that the parameter name
>"max_workers" and documentation implies that it will spawn processes as needed
>up to *max_workers* based
Kyle Stanley added the comment:
> I hope it is fixed now.
> Thanks, Kyle!
No problem, thanks for looking over it.
Let me know if the warning comes up again. If it does, I'll be sure to look
into it.
--
___
Python trac
Kyle Stanley added the comment:
> I think this should be fixed like ThreadPoolExecutor.
Are there are any downsides or complications with changing this behavior for
ProcessPoolExecutor to consider, such as what I mentioned above? From my
understanding, there would be a performance pena
Kyle Stanley added the comment:
> It would certainly be better to start the worker processes on demand. It
> probably also requires careful thought about how to detect that more workers
> are required.
Alright. In that case, I'll do some experimentation when I get the chance
Kyle Stanley added the comment:
Update: I have a bit of good news and not so great news.
The good news is that I had some time to work on this again, specifically with
isolating the failure in test__xxsubinterpreters.DestroyTests. Locally, I added
a few temporary "@unittest
Kyle Stanley added the comment:
I also just realized that I can run "test.test__xxsubinterpreters.DestroyTests"
by itself with:
./python -m test test__xxsubinterpreters.DestroyTests -j200 -F -v
For some reason, I hadn't thought of running that class of tests by itself
Kyle Stanley added the comment:
> I also just realized that I can run
> "test.test__xxsubinterpreters.DestroyTests" by itself with:
> ./python -m test test__xxsubinterpreters.DestroyTests -j200 -F -v
Oops, the correct syntax is:
./python -m test test__xxsubinterpreters -
Kyle Stanley added the comment:
I just made a rather interesting discovery. Instead of specifically focusing my
efforts on the logic with interp_destroy(), I decided to take a closer look at
the failing unit test itself.
The main test within DestroyTests that's failing is the foll
New submission from Kyle Stanley :
This feature enhancement issue is based on the following python-ideas thread:
https://mail.python.org/archives/list/python-id...@python.org/thread/ZSUIFN5GTDO56H6LLOPXOLQK7EQQZJHJ/
In summary, the main suggestion was to implement a new parameter called
Change by Kyle Stanley :
--
components: +Library (Lib)
___
Python tracker
<https://bugs.python.org/issue39349>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kyle Stanley added the comment:
As of now, I have the implementation for ThreadPoolExecutor working correctly,
and a unit test added to ensure its behavior. It was a bit more involved than I
originally anticipated, as I had to make a minor change in the _worker()
function to allow the new
Kyle Stanley added the comment:
> It was a bit more involved than I originally anticipated, as I had to make a
> minor change in the _worker() function to allow the new parameter to be
> compatible with wait (which is important, as it prevents dangling threads).
Never mind, I just
Kyle Stanley added the comment:
I now have a working implementation, for both ThreadPoolExecutor and
ProcessPoolExecutor. I've also ensured that the tests I added are not
vulnerable to race conditions with the following:
```
[aeros:~/repos/aeros-cpython]$ ./python -m
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
201 - 300 of 456 matches
Mail list logo
