Kyle Stanley added the comment:
> This is already backported to 3.6. I am not sure about what gets backported
> to 3.5 right now, I don't even see a 'Backport to 3.5' label on Github (which
> made me think we are discouraged to backport to 3.5). I can work on a manu
New submission from Kyle Stanley :
Last month, several tests were moved into test_importlib
(https://bugs.python.org/issue19696): "test_pkg_import.py",
"test_threaded_import.py", and "threaded_import_hangers.py".
Those tests were created quite a while ago thoug
Kyle Stanley added the comment:
I'm not entirely certain as to which parts should be modernized, and which ones
can remain the same. A large part of my uncertainty is that there are no header
comments for "test_pkg_import.py" to explain the test coverage, so I don'
Change by Kyle Stanley :
--
nosy: +eric.snow, ncoghlan
___
Python tracker
<https://bugs.python.org/issue37890>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kyle Stanley :
--
stage: -> needs patch
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue37890>
___
___
Python-bugs-list
Kyle Stanley added the comment:
Ah okay, I wasn't sure what exactly would be involved with the "modernization"
process, so those points were just rough ideas more than anything. I haven't
started working on anything yet since I figured it'd be worthwhile to wait
Kyle Stanley added the comment:
> This might be a decent way to prevent the AttributeErrors, but still allows
> for differentiation of actual None values
Another alternative solution might be to use hasattr() before getattr(), if it
is not desirable for test_pkg_import.py to
Kyle Stanley added the comment:
> A key question here is why are you trying to avoid the AttributeError case so
> much?
> but there's a reason that we don't have attribute existence tests before
> every single attribute access throughout the test suite
Hmm, good
Kyle Stanley added the comment:
> I would just read through the other tests files under test_importlib to see
> how other tests were done.
Okay, I'll start with that and report back with any ideas for potential changes
to test_pkg_imp
Kyle Stanley added the comment:
Reopening the issue for adding the documentation clarification, that comparing
the values view of two dictionaries will always return false (as was suggested
in the ML discussion
https://mail.python.org/archives/list/python-...@python.org/message
Change by Kyle Stanley :
--
stage: resolved -> patch review
___
Python tracker
<https://bugs.python.org/issue37585>
___
___
Python-bugs-list mailing list
Un
New submission from Kyle Stanley :
In the documentation for the NotImplemented constant
(https://docs.python.org/3/library/constants.html#NotImplemented), the only use
case mentioned is for binary special methods, (such as object.__eq__(other)).
However, based on a conversation in a recent
Kyle Stanley added the comment:
> python-dev likely isn't the right place. That is a forum for more mature
> ideas.
Agreed, that idea should be posted to python-list if they're having issues
posting to python-ideas. Python-dev certainly wouldn't be
Change by Kyle Stanley :
--
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue37812>
___
___
Python-bugs-list mailing list
Unsubscrib
Kyle Stanley added the comment:
> May I suggest directing your efforts towards fixing known bugs or
> implementing requested features. It isn't our goal to create more work for
> one another
There frequently is value in improving code readability, as it can improve
maintain
Kyle Stanley added the comment:
> Skipping this call for non-main thread in proactor implementation makes sense.
How do we identify whether or not set_wakeup_fd() is being called from a
non-main thread?
--
nosy: +aeros167
___
Python trac
Kyle Stanley added the comment:
> How do we identify whether or not set_wakeup_fd() is being called from a
> non-main thread?
Never mind, I think I found the answer to my own question and tested a patch
locally, I'll open a PR.
--
___
Change by Kyle Stanley :
--
keywords: +patch
pull_requests: +15163
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/15477
___
Python tracker
<https://bugs.python.org/issu
Change by Kyle Stanley :
--
keywords: +needs review -patch
___
Python tracker
<https://bugs.python.org/issue34679>
___
___
Python-bugs-list mailing list
Unsub
Kyle Stanley added the comment:
> Kyle, thanks for the fix.
> I have basically the same change in my PR but with test and news note.
No problem, that works for me. I was mostly just trying to help with resolving
some of the release blockers for
Change by Kyle Stanley :
--
nosy: +mark.dickinson, meador.inge
___
Python tracker
<https://bugs.python.org/issue23933>
___
___
Python-bugs-list mailing list
Unsub
Kyle Stanley added the comment:
Thanks for the feedback Vedran and Raymond.
> It is not the purpose of the docs to list use cases. Mostly we say what
> something does or how it is defined. As Vedran says, how people use it is
> their own business.
The underlying issue here se
Kyle Stanley added the comment:
> Would it be viable to rephrase the existing section in a manner that explains
> the functional purpose of NotImplemented without revolving around its use
> case in binary special methods?
To expand further upon this, here's an initial idea for
Kyle Stanley added the comment:
Thanks for the explanation.
> Of course, you might argue that _once Python has NotImplemented_, it can be
> used elsewhere - but as I said, I don't think it should be encouraged.
Hmm, okay. My understanding of Raymond's explanation was mo
Kyle Stanley added the comment:
Ronald, is it feasible that the changes made in
https://github.com/python/cpython/pull/14748/files to THREAD_STACK_SIZE in
Python/thread_pthread.h could be causing intermittent failures for the Azure
macOS PR tests?
In a recent PR (https://github.com/python
Kyle Stanley added the comment:
> As you say, we currently have only one usage of NotImplemented outside its
> intended purpose. Maybe we should wait to see whether it becomes at least a
> little bit more popular, before thinking about blessing it.
> I know at least 3 in CPyt
Kyle Stanley added the comment:
It looks like the Azure macOS tests timed out again in the recently opened
PR-15688. Specifically, for test_multiprocessing_spawn and test_functools (both
of which also timed out in PR-15651, which Victor mentioned earlier):
0:26:41 load avg: 2.89 [418/419/1
Kyle Stanley added the comment:
> Any plan to reapply my change, or fix it?
I can try to help with this. I'm not the most familiar with the internals of
asyncio, but I think it would provide a good learning experience.
--
nosy: +
Change by Kyle Stanley :
--
pull_requests: +15390
pull_request: https://github.com/python/cpython/pull/15735
___
Python tracker
<https://bugs.python.org/issue34
Kyle Stanley added the comment:
I've opened PR-15735 which applies the same functionality as Victor's PR-13786,
but adds the public getter and setter methods (for both AbstractEventLoop and
BaseEventLoop) as requested by Andrew.
Since this is still causing intermittent CI fai
Change by Kyle Stanley :
--
keywords: +patch
pull_requests: +15757
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16147
___
Python tracker
<https://bugs.python.org/issu
Kyle Stanley added the comment:
Created GH-16147 for replacing the *from_what* argument with *whence* in the IO
tutorial.
I would like to consider following up on this with another PR that adds the IO
constants `SEEK_SET`, `SEEK_CUR`, and `SEEK_END` to the tutorial. Those
constants would
Kyle Stanley added the comment:
> Thanks you Kyle!
No problem, thanks for merging it Antoine!
What do you think of the followup PR to make use of the SEEK_* constants listed
in the documentation? I think it would be useful to at least mention them in
the tutorial, or even make use of t
Kyle Stanley added the comment:
> FWIW, I've confirmed again that the exact same script on the same machine
> seems fine under Python 3.x. Given the imminent demise of Python 2, perhaps
> this issue is just destined to be an unsolved historical oddity.
Since it doesn't s
Kyle Stanley added the comment:
Upon digging through Modules/_xxsubinterpretersmodule.c, I noticed that on line
2059, `PyInterpreterState_Delete(interp);` is commented out
(https://github.com/python/cpython/blob/bf169915ecdd42329726104278eb723a7dda2736/Modules/_xxsubinterpretersmodule.c
Kyle Stanley added the comment:
Note that I'm not particularly experienced with the c-api, I'm just trying to
take a stab at understanding why the buildbot failure is occuring.
--
___
Python tracker
<https://bugs.python.o
Kyle Stanley added the comment:
Clarification: In the above comment when I was referring to the commit made by
Eric Snow, I meant to link to
https://github.com/python/cpython/commit/7f8bfc9b9a8381ddb768421b5dd5cbd970266190.
--
___
Python tracker
Kyle Stanley added the comment:
Upon further reading of the documentation and some experimentation, it would
definitely not make sense to call `PyInterpreterState_Delete` here (since we're
only closing the sub-interpreter in the current thread), so that's not the
issue. I still ha
Kyle Stanley added the comment:
Clarification:
"If I'm not mistaken doesn't mean that the `return -1` within ..."
Should instead be:
"If I'm not mistaken doesn't this mean that the `return -1` within ..."
(I am really looking forward to moving issue
Kyle Stanley added the comment:
I believe I found a potential fix, see
https://bugs.python.org/issue37224?@ok_message=msg%20352516%20created%0Aissue%2037224%20message_count%2C%20messages%20edited%20ok&@template=item#msg352514.
Should I attach the PR to that issue or this
Kyle Stanley added the comment:
Upon further consideration, I don't think this will address the issue. If the
RuntimeError was not being raised, this failure would be consistent rather than
intermittent.
I think I have have gotten a bit mixed up, even if the return value of
PyErr_F
Kyle Stanley added the comment:
> Thanks, Kyle!
No problem, and thanks for all of the help from Andrew, Yury, and Victor!
> IMHO it will make asyncio more reliable, especially for tests on the CI.
Awesome, that was my primary intention. (:
> If it becomes an issue in Python 3.9
Kyle Stanley added the comment:
> I'm one of the first to advocate to replace ugly macros with clean static
> inline functions. Macros are evil and can be too easily misused.
As someone who has only more recently started learning the C-API (and C in
general), I'm certa
Kyle Stanley added the comment:
Is there a currently reliable way of accessing the GIL functions within the
sub-interpreters, without causing deadlock issues? I was trying to follow the
advice in the documentation
(https://docs.python.org/3/c-api/init.html?highlight=global%20interpreter
Change by Kyle Stanley :
--
keywords: +patch
pull_requests: +15879
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16293
___
Python tracker
<https://bugs.python.org/issu
Kyle Stanley added the comment:
For an updated explanation of the PR, see https://bugs.python.org/msg352835 or
the comments in the PR itself.
--
stage: patch review ->
___
Python tracker
<https://bugs.python.org/issu
Kyle Stanley added the comment:
> You can find my email in Git, and I'm on Zulip and Discourse; and I'd be
> happy to start or follow a thread in a forum you think appropriate. Or if
> you'd rather drop it entirely, that's fine too.
I think opening a thread in
Kyle Stanley added the comment:
> Is there an "aesthetic code cleanup" patch that's ever turned out well? ;-)
>From what I can tell, any remotely extensive aesthetic code patch I've seen
>has been highly controversial. I think they can have value in some cases
Change by Kyle Stanley :
--
nosy: +aeros167
___
Python tracker
<https://bugs.python.org/issue38242>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kyle Stanley added the comment:
> We have to document that Process objects use a third kind of stream object
> that doesn't match either the old or new APIs, and how this one works
>From my perspective, this point would have the largest user learning cost due
>to the strea
New submission from Kyle Stanley :
Currently, for the recently added coroutine `loop.shutdown_default_executor()`,
the executor shutdown can wait indefinitely for the threads to join. Under
normal circumstances, waiting on the threads is appropriate, but there should
be a timeout duration in
Change by Kyle Stanley :
--
keywords: +patch
pull_requests: +15941
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16360
___
Python tracker
<https://bugs.python.org/issu
Kyle Stanley added the comment:
> Andrew, do you want me to submit a PR or you can do it?
Since this has been elevated to a release blocker, I wouldn't mind helping to
revert this ASAP. I can open a PR to fix it today.
--
___
Python
Kyle Stanley added the comment:
> You'll need to be careful to only revert the new functions & the
> asyncio.Stream class.
So far the trickiest part has proven to be the tests (specifically
test_streams.py) and keeping the deprecation warning for passing explicit loop
argu
Kyle Stanley added the comment:
Currently focusing on the Lib/asyncio/* and Lib/test/* changes. Working on doc
changes next, but that should be significantly easier.
In addition to
https://github.com/python/cpython/commit/23b4b697e5b6cc897696f9c0288c187d2d24bff2
(main commit from Andrew
Change by Kyle Stanley :
--
keywords: +patch
pull_requests: +16024
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16445
___
Python tracker
<https://bugs.python.org/issu
Change by Kyle Stanley :
--
pull_requests: +16035
pull_request: https://github.com/python/cpython/pull/16455
___
Python tracker
<https://bugs.python.org/issue38
Kyle Stanley added the comment:
This should no longer be a release blocker for 3.8 with the reversion of the
new asyncio streaming API in GH-16455.
--
nosy: +aeros167
___
Python tracker
<https://bugs.python.org/issue38
Change by Kyle Stanley :
--
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue38242>
___
___
Pyth
Kyle Stanley added the comment:
> I've reverted the code. Andrew, would really appreciate if you could quickly
> do a post commit review.
Oops, I'll reopen it.
--
___
Python tracker
<https://bugs.py
Change by Kyle Stanley :
--
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue38242>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Kyle Stanley :
--
stage: resolved -> commit review
___
Python tracker
<https://bugs.python.org/issue38242>
___
___
Python-bugs-list mailing list
Un
Kyle Stanley added the comment:
Closed by the new asyncio stream API reversion in GH-16485 and GH-16482.
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Kyle Stanley added the comment:
Welcome back from the OOOS break Mariatta!
> My question (and it's just that) is whether we've made a decision to prefer
> one formatting syntax over others (outside of examples discussing the
> formatting approaches themselves).
I agree t
Kyle Stanley added the comment:
> so it would be a good candidate for the "newcomer friendly" label
Never mind, just noticed this was already labeled as newcomer friendly. I only
saw the "easy" label at first. (:
If consensus is reached for this, we can open a separa
Kyle Stanley added the comment:
I can try to work on fixing this.
--
nosy: +aeros167
___
Python tracker
<https://bugs.python.org/issue38356>
___
___
Python-bug
Kyle Stanley added the comment:
> I definitely think we should not modify any code in the stdlib just to switch
> to f-strings.
Does this also apply to updating code to use f-strings in an area that's
already being modified for a functional purpose?
I agree that that we shoul
Kyle Stanley added the comment:
First I'll work on adding a new method. Here's a few potential names, ordered
roughly by my preferences:
1) join_threads()
2) shutdown_threads()
3) shutdown_threadpool()
The first and second options are roughly equal, but I think join_threads()
Kyle Stanley added the comment:
> Another consideration is if we want this method to join the threads to be
> called in `ThreadedChildWatcher.close()`.
An additional benefit of having the method called from `close()` is that it
means we don't have to modify the tests dir
Change by Kyle Stanley :
--
keywords: +patch
pull_requests: +16140
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16552
___
Python tracker
<https://bugs.python.org/issu
Kyle Stanley added the comment:
> For the most part, templating examples can be switched to the .format() style
> but shouldn't be switched to f-strings.
Is there no specific use case for the older "%s" % sub template that .format()
doesn't have?
> The former
Change by Kyle Stanley :
--
stage: patch review -> commit review
___
Python tracker
<https://bugs.python.org/issue38344>
___
___
Python-bugs-list mai
Change by Kyle Stanley :
--
stage: backport needed -> commit review
___
Python tracker
<https://bugs.python.org/issue38355>
___
___
Python-bugs-list mai
Change by Kyle Stanley :
--
stage: backport needed -> commit review
___
Python tracker
<https://bugs.python.org/issue38359>
___
___
Python-bugs-list mai
Kyle Stanley added the comment:
> Kyle Stanley proposed a fix: PR 16293.
Note that I'm not confident about the fix I proposed in GH-16293, it was more
of an idea to fix the intermittent failures more than anything. It definitely
needs review from someone knowledgeable about sub-inte
Change by Kyle Stanley :
--
nosy: +aeros
___
Python tracker
<https://bugs.python.org/issue31387>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kyle Stanley :
--
nosy: +aeros
___
Python tracker
<https://bugs.python.org/issue28533>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kyle Stanley added the comment:
> Is it still open? What else needs to be done?
Yes, this patch needs to be translated into a GitHub PR. See
https://devguide.python.org/pullrequest/ for more information on our PR
workflow if you're not already familiar with it. Since naught101 wrote
Change by Kyle Stanley :
--
nosy: +aeros
___
Python tracker
<https://bugs.python.org/issue38323>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kyle Stanley added the comment:
I can confirm Victor's method of reproducing the failure consistently, by using
asyncio.sleep(1e-9) within `RunCoroutineThreadsafeTests.add()` instead of the
current asyncio.sleep(0.05).
I also experimented with adjusting the sleep time, to figure ou
Kyle Stanley added the comment:
> I'm able to reproduce the issue locally using the command:
./python -m test test_asyncio
--match=test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests.test_close_kill_running
-v -F -j20 --timeout=30.0
I was unable to reproduce this local
Kyle Stanley added the comment:
> IHMO a test must not depend on time.
I would agree, the tests should optimally not depend on time. My above comment
was primarily to confirm that the failure was able to be consistently
reproduced, along with the minimum conditions to do so.
Yury had b
New submission from Kyle Stanley :
Proposal:
Deprecate the alternative process watcher implementation to
ThreadedChildWatcher, MultiLoopChildWatcher.
Motivation:
The idea for this proposal came from a comment from Andrew Svetlov in GH-16552:
"I believe after polishing ThreadedChildWatch
Change by Kyle Stanley :
--
assignee: -> aeros
nosy: +vstinner
status: open -> pending
___
Python tracker
<https://bugs.python.org/issue38591>
___
___
Pyth
Kyle Stanley added the comment:
> Didn't we just add MultiLoopChildWatcher in 3.8?
Yep, that's correct:
https://docs.python.org/3/library/asyncio-policy.html#asyncio.MultiLoopChildWatcher
I wasn't aware of that, but it would explain the current lack of usage. I'm
Kyle Stanley added the comment:
> Speaking of watchers -- big +1 from me to drop them all at some point. I
> would start as early as 3.9.
Yeah that was my initial plan, to start the deprecation in 3.9 and finalize the
removal in 3.11. We might be able to make an excepti
Change by Kyle Stanley :
--
title: Deprecating MultiLoopChildWatcher -> Deprecate Process Child Watchers
___
Python tracker
<https://bugs.python.org/issu
Kyle Stanley added the comment:
> Kyle, why are you resetting the status to "Pending"?
That was an accident, I think I had that set already on the page and submitted
my comment just after you did yours.
I'm going to change the title of the issue to "Deprecate Proc
Kyle Stanley added the comment:
> I think FastChildWatcher and SafeChildWatcher should go, ThreadedChildWatcher
> should be kept default and MultiLoopChildWatcher is an option where
> ThreadedChildWatcher is not satisfactory.
Okay, I think I can understand the reasoning here. Do
Kyle Stanley added the comment:
> > If asyncio is only run from the main thread, FastChildWatcher is safe, fast
> > and has low memory footprint, no?
> Unfortunately, no. FastChildWatcher is safe if you can guarantee that no code
> executed in asyncio main thread AND
Kyle Stanley added the comment:
> But it spawns a new Python thread per process which can be a blocker issue if
> a server memory is limited.
I understand that there's *some* overhead associated with spawning a new
thread, but from my impression it's not substantial
Kyle Stanley added the comment:
> Actually, since Andrew also agrees that we need to deprecate passing
> coroutines to wait(), I'll keep this issue open until we add an actual
> DeprecationWarning in 3.8.
Since 3.8 has been released and the deprecation notice is in th
Kyle Stanley added the comment:
> I think we can add `DeprecationWarning` for 3.9.
If we add the deprecation warning just for 3.9, would the removal release also
be pushed forward?
> Honestly, we just missed the issue when were prepared for 3.8
Yeah that's definitely understand
Kyle Stanley added the comment:
> It was the first time I saw a deprecation clearly documented in a final
> release that didn't have an associated deprecation warning.
I want to clarify that this may be a more common occurrence than I'm realizing,
I'm not entirely c
Change by Kyle Stanley :
--
nosy: +serhiy.storchaka
___
Python tracker
<https://bugs.python.org/issue21002>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kyle Stanley added the comment:
> Is anyone able to make a call on whether this issue should be closed, or
> alternatively give some guidance on what work this issue should encompass?
Added Serhiy to the nosy list, since he's an active maintainer for the re
module.
--
n
Kyle Stanley added the comment:
Sounds good, I'll work on opening a PR.
--
___
Python tracker
<https://bugs.python.org/issue34790>
___
___
Python-bugs-l
Kyle Stanley added the comment:
> Regarding 3.8 release notes update -- not sure if it is needed flr docs-only
> change.
I'm not certain if the entry is necessary; my main concern is just that it's
already present in the 3.8 release notes/whatsnew without anywhere to l
Change by Kyle Stanley :
--
pull_requests: +16502
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16975
___
Python tracker
<https://bugs.python.org/issu
Kyle Stanley added the comment:
GH-16975 Is a simple fix for the asyncio.wait() whatsnew entry for 3.8. I'll
implement the deprecation warning and add a 3.9 whatsnew entry in a separate
PR, since those changes won't be backported.
--
stage: pa
1 - 100 of 416 matches
Mail list logo
