New submission from Guido van Rossum :
Now that TaskGroup is merged (see bpo-46752) we might consider adding some form
of cancel scopes (another Trio idea).
There's a sensible implementation we could use as a starting point in
@asvetlov's async-timeout package (https://github.co
Guido van Rossum added the comment:
I've created a separate issue for cancel scopes: bpo-46771.
--
___
Python tracker
<https://bugs.python.org/is
Change by Guido van Rossum :
--
keywords: +patch
pull_requests: +29526
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31270
___
Python tracker
<https://bugs.python.org/issu
Change by Guido van Rossum :
--
nosy: +dhalbert
___
Python tracker
<https://bugs.python.org/issue46752>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Sure, we should create the best possible solution.
We have no CI in the stdlib that checks type annotations, so those should
probably be moved to a stub file in typeshed. (Ditto for asyncio taskgroups.py.)
Using the new .cancelling()/.uncancel() API added
Guido van Rossum added the comment:
I have a PR up to typeshed to add the new Task methods and a new stub file
taskgroups.pyi: https://github.com/python/typeshed/pull/7240
--
___
Python tracker
<https://bugs.python.org/issue46
Change by Guido van Rossum :
--
nosy: +tinchester
___
Python tracker
<https://bugs.python.org/issue46771>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Alex, the goal here is not to replicate every Trio feature or behavior. For
example I don't think that asyncio is likely to get level cancellation in 3.11,
but we can certainly see if we can do something about some of the edge cases
you mention, lik
Guido van Rossum added the comment:
OK.
1. Please have a look at how .cancelling()/.uncancel() works (there's an
example of it in TaskGroup) to solve that particular problem without using the
cancel message.
2. Suppose you could make (backwards compatible) changes to asyncio. What
Guido van Rossum added the comment:
Oh, wait. The new Task.cancelling() API helps tell the difference between the
*parent* task being cancelled "from outside" vs. the task group itself
cancelling the parent task so as to break out of an await like the following:
async with TaskGr
Guido van Rossum added the comment:
Maybe historically constrained type vars predated bound type vars. This could
have influenced the way PEP 484 was written and then the docs were derived from
the PEP.
But yes, this should be fixed in as many places as possible (including the mypy
docs
Guido van Rossum added the comment:
I hesitate to add yet another stack at this fundamental level.
The Task.cancel() method returns a bool which indicates whether any state
changed.
When multiple cancellations happen concurrently, all but the first will return
False, and anything that
Guido van Rossum added the comment:
@Tin The sad path is just a race, right? If the web server had disconnected
just a tad later, __aexit__() would already have returned and await
something_else() would already be running. So you can't make any promises if
you write your code tha
Guido van Rossum added the comment:
Hm, I see. So the problem is that in the interval between move_on's calls to
t.cancel() and t.uncancel(), if the web server calls t.cancel() that will just
return False. So the web server would have to implement some other mechanism
for cance
Guido van Rossum added the comment:
FWIW it looks like this part of taskgroups is vulnerable to a similar race:
https://github.com/python/cpython/blob/6f1efd19a70839d480e4b1fcd9fecd3a8725824b/Lib/asyncio/taskgroups.py#L212-L232
Deleting the two lines I mentioned won't fix it here; a
Guido van Rossum added the comment:
> (I note that there is no documented way to retrieve the cancel message;
> you're supposed to access the protected `_cancel_message` attribute,
> apparently. Looks like we forgot something there.)
Oh, it's passed to the CancelledError
Guido van Rossum added the comment:
> > I note that there is no documented way to retrieve the cancel message
> Does retrieving it from the CancelledError that is bubbling up suffice? Or do
> you need to be able to obtain it from the future object?
I'm not sure yet (if any
Guido van Rossum added the comment:
Lots of food for thought! There seem to be mostly two discussions: API design
for the new asyncio cancel scopes (do we make it more like Trio or more like
async-timeout?); and cancel semantics in edge cases.
I'll pass on the API design for n
Change by Guido van Rossum :
--
pull_requests: +29541
pull_request: https://github.com/python/cpython/pull/31398
___
Python tracker
<https://bugs.python.org/issue46
Change by Guido van Rossum :
--
pull_requests: +29542
pull_request: https://github.com/python/cpython/pull/31398
___
Python tracker
<https://bugs.python.org/issue46
Guido van Rossum added the comment:
+1 on both aspects of the plan.
--
___
Python tracker
<https://bugs.python.org/issue46771>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
New changeset d85121660ea50bbe8fbd31797aa6e4afe0850388 by Guido van Rossum in
branch 'main':
bpo-46752: Slight improvements to TaskGroup API (GH-31398)
https://github.com/python/cpython/commit/d85121660ea50bbe8fbd31797aa6e4
Change by Guido van Rossum :
--
pull_requests: +29551
pull_request: https://github.com/python/cpython/pull/31411
___
Python tracker
<https://bugs.python.org/issue46
Guido van Rossum added the comment:
Adding jwilk back (a bpo interaction with browser form caching makes this
happen frequently).
--
nosy: +jwilk
___
Python tracker
<https://bugs.python.org/issue46
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue45390>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
The 3rd party context managers are somewhat of a red herring.
These are just try/except or try/finally blocks.
The inner cm (cm4) is irrelevant, it will see CancelledError and presumably
that bubbles out. If it does any resource cleanup we can replace it
Guido van Rossum added the comment:
> Can I also get comments on my proposal for the "scope" parameter? Is there a
> use case it would not solve?
It looks more complicated -- the extra parameter needs to be passed around via
the task and then into the CancelledError exce
Guido van Rossum added the comment:
(Sam Bull)
> To expand on this point, I've been looking at solving the race conditions in
> async-timeout. To see how such a race condition can end up with a task never
> exiting, take a look at this example:
> https://github.com/aio-l
Guido van Rossum added the comment:
[Alex]
> The current backward incompatible changes in cancellation behavior are
> already causing 10 tests to fail in the AnyIO test suite. I'm trying to find
> an alternate solution that does not break anything.
Are you sure that the tes
Guido van Rossum added the comment:
[Sam]
> It will probably work in this case. But, what about more complex cases? If
> there are 2 different timeouts and the possibility of a user cancellation,
> and we have a count of 2 cancellations, then what happened? 2 timeouts, or 1
>
Guido van Rossum added the comment:
PS. The cancel count can work whether or not cancel() returns without setting
must-cancel (or cancelling the underlying future/task) when there's already a
cancellation in progress. Other things may be different though. We have to look
into
Guido van Rossum added the comment:
Sounds good to me. (I don’t care what happens at runtime but I want to
support the folks who do.)--
--Guido (mobile)
--
___
Python tracker
<https://bugs.python.org/issue45
Change by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<https://bugs.python.org/issue45100>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
I would like to go on record (again) as preferring to get rid of the
cancel-message parameter altogether. Let's deprecate it. When we initially
designed things without a cancel message we did it on purpose -- "cancellation"
is a sin
Guido van Rossum added the comment:
> If some code is used together with timeout() and this code calls
> `.cancel()` but forgot about `.uncancel()` in try/except/finally --
> timeout() never raises TimeoutError.
Could you show an example? I'm not sure from this description wh
Guido van Rossum added the comment:
But that example is made-up. Is there a real-world situation where you need to
know the call site, and it wouldn't be obvious from other log messages?
Directly cancelling a task without also somehow catching the cancellation (like
in the timeout or
Guido van Rossum added the comment:
To make this cleanly interact with timeout, TaskGroup etc., the CancelOnEvent
class should have a "did-I-cancel" flag which is set in the _cancel_on_event()
callback. Then if that flag is set it should call .uncancel(), and if that
returns a val
Guido van Rossum added the comment:
Okay, let's change the error handling. @Kumar, can you handle that?
@Victor, the refleak is unrelated to the error handling right? Presumably the
leak is imaginary -- the deep-frozen interned strings should be accounted for
somehow. @Kumar do you
Guido van Rossum added the comment:
We should really stop appending to a closed issue.
Anyway, raising ExceptionGroup is backwards incompatible, since "except
CancelledError" wouldn't cancel the group.
--
___
Python
Guido van Rossum added the comment:
> Not leaking memory at exit matters when Python is embedded
> in an application.
Sure, but "leaks" caused by deep-freezing cannot be solved by freeing up the
deep-frozen memory -- the solution must be to update the accounting somewher
Guido van Rossum added the comment:
I will now merge GH-31513 (cancel counts). Once that's in you can merge main
into your timeout PR (GH-31394) and then that can land soon (I'd like to review
it once more).
--
___
Python track
Guido van Rossum added the comment:
That's pretty mysterious. The deep-freeze code isn't on the stack for either of
those, but allocation of new unicode string objects is. I'm guessing these are
somehow leaked by the interning, but I don&#
Guido van Rossum added the comment:
A few examples of issues brought up by Kohl:
- While the PLR explicitly states that “x < y calls x.__lt__(y)”
[20, §3.3.1.] this is actually false.
There are cases where x < y does not call x.__lt__(y)
and there are other cases where x.__lt__
Guido van Rossum added the comment:
Another:
- The description of this name binding and resolution process
in the PLR [20, §4.2.] is unfortunately not particularly clear.
(I found this to be the case too, and wrote up what I found:
https://gvanrossum.github.io/formal/scopesblog.html
Guido van Rossum added the comment:
New changeset 7fce1063b6e5a366f8504e039a8ccdd6944625cd by Tin Tvrtković in
branch 'main':
bpo-46771: Implement task cancel requests counter (GH-31513)
https://github.com/python/cpython/commit/7fce1063b6e5a366f8504e039a8ccd
Guido van Rossum added the comment:
Could you just have a global task group that owns these long-running tasks? It
could be embedded in a "toplevel" task that is created using
asyncio.create_task() (which won't be deprecated). To shut down all
long-running tasks at the end, j
Guido van Rossum added the comment:
-1. Libraries that manage their own tasks should continue to do so, until they
are ready to adopt TaskGroup. Trying to "own" (and wait for) tasks created by a
library sounds like a recipe for disaster if the library wasn't expecting that.
Guido van Rossum added the comment:
> How it should be handled? Currently PyUnicode_InternInPlace ignores any
> errors and does not return it. It would be backwards-incompatible to change
> that, moreover as I explained in
> https://github.com/python/cpython/pull/30683#discussio
Guido van Rossum added the comment:
The implementation of asyncio.TaskGroup isn't all that complicated (and the new
"cancel count" API helps). I recommend that you build one that satisfies your
requirements yourself, or convince the authors of some other package like
Quattro
Guido van Rossum added the comment:
(FWIW I would close this issue but I'll wait to see if @asvetlov has something
to add.)
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
Let's concentrate the discussion in the other issue.
--
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.pyth
Guido van Rossum added the comment:
New changeset eb002dbe0da9622245a355db5f0cd5aa2fc70b40 by Kumar Aditya in
branch 'main':
bpo-46712: Share global string identifiers in deepfreeze (GH-31261)
https://github.com/python/cpython/commit/eb002dbe0da9622245a355db5f0cd5
Change by Guido van Rossum :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> resource usage
___
Python tracker
<https://bugs.python
Guido van Rossum added the comment:
Thanks! Marking as duplicate.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Fix incorrect use of directives in asyncio documentation
___
Python tra
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue46777>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Guido van Rossum :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
> PEP 587 introduced PyStatus to Python startup code which let the
> Py_Initialize() caller to decide how to handle errors ;-) For example, you
> can open a graphical popup rather than killing the process with SIGABRT
> (Py_FatalError() beh
Guido van Rossum added the comment:
If the problem is in mypy, it should be filed in the mypy tracker, not here.
--
___
Python tracker
<https://bugs.python.org/issue44
Change by Guido van Rossum :
--
resolution: -> third party
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
Raymond, I agree that this is going too far. I believe the OP has taken the
position that "abstract" has only one meaning and it is defined by
inspect.isabstract(). I disagree with this.
An ABC is an ABC is an ABC, and it provides certain fun
Change by Guido van Rossum :
--
pull_requests: +29748
pull_request: https://github.com/python/cpython/pull/31623
___
Python tracker
<https://bugs.python.org/issue46
Guido van Rossum added the comment:
Everyone,
I've sent a PR (which I expect will make it into alpha 6) that restores the old
cancel() semantics. This should make Tin happy, but I think we'll still have to
have a longer discussion about the downsides.
https://github.com/python/cp
Guido van Rossum added the comment:
New changeset 7d611b4cabaf7925f5f94daddf711d54aeae2cf9 by Guido van Rossum in
branch 'main':
bpo-46771: Remove two controversial lines from Task.cancel() (GH-31623)
https://github.com/python/cpython/commit/7d611b4cabaf7925f5f94daddf711d
Guido van Rossum added the comment:
Oops.
So this is an intentional feature -- Protocol replaces __init__ so that you
can't (accidentally) instantiate a protocol. And the code to do this has
changed a couple of times recently to deal with some edge cases. At least one
of the PRs w
Guido van Rossum added the comment:
Would it make sense to enforce the no-instantiation rule in __new__ instead of
__init__?
--
___
Python tracker
<https://bugs.python.org/issue44
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue46836>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
So this bug is referenced when pydevd encounters some problem with 3.11a5+:
https://github.com/fabioz/PyDev.Debugger/issues/213
Since the link to this bug is apparently baked into the error messages printed
by pydevd, I am adding this comment to this old
Guido van Rossum added the comment:
New changeset cc400585fab02994255f21ae8183d5f147236815 by Kumar Aditya in
branch 'main':
bpo-46877: export unittest.doModuleCleanups in unittest package (#31613)
https://github.com/python/cpython/commit/cc400585fab02994255f21ae8183d5
Change by Guido van Rossum :
--
components: +Library (Lib)
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: enhancement -> behavior
___
Python tracker
<https://bugs.python
Guido van Rossum added the comment:
Couldn't there be a subtler solution than rolling back GH-19371?
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
Mypy seems to allow this:
from typing import NamedTuple, TypeVar, Generic, List, Tuple
T = TypeVar("T")
class New(NamedTuple, Generic[T]):
x: List[T]
y: Tuple[T, T]
It's true that pyright doesn't, but maybe that's becaus
Guido van Rossum added the comment:
So if it doesn't work in mypy why bother making it work at runtime? Is there an
actual use case that broke? (There might be, but probably esoteric if nobody's
run into it until now.)
--
___
Pyth
Guido van Rossum added the comment:
Can you be more specific about your use cases?
--
___
Python tracker
<https://bugs.python.org/issue43923>
___
___
Python-bug
Guido van Rossum added the comment:
Okay, that's a sensible use case.
I do doubt your intuition of preferring named tuples over dataclasses a bit.
This seems to encourage premature optimization. I'd say for simple cases use
plain tuples (most performant), for complex cases use d
Guido van Rossum added the comment:
There is general confusion as to which part of the traceback is truncated. If I
have main() -> f() -> g() -> error(), and the limit is 2, does it print main()
-> f(), or does it print g() -> error()? (I'm not even sure which would be
Guido van Rossum added the comment:
New changeset b465b606049f6f7dd0711cb031fdaa251818741a by Niklas Rosenstein in
branch 'main':
bpo-41370: Evaluate strings as forward refs in PEP 585 generics (GH-30900)
https://github.com/python/cpython/commit/b465b606049f6f7dd0711cb031fdaa
Guido van Rossum added the comment:
Checked in (after substantial changes, pairing with Keir).
--
assignee: -> gvanrossum
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Changes by Guido van Rossum:
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1015>
__
___
Python
Changes by Guido van Rossum:
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1017>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mai
Changes by Guido van Rossum:
--
assignee: -> gvanrossum
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
New submission from Guido van Rossum:
Bill Janssen's patch for server-side ssl support (and certificate
support). This still needs style cleanup, but is leak-free and passes tests.
--
assignee: gvanrossum
components: Extension Modules
files: ssl-svr.diff
keywords: patch
messages:
Guido van Rossum added the comment:
And another file that has a utility to be placed in Tools/...
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1018>
__
tools-diff
Description:
Changes by Guido van Rossum:
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1018>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mai
Changes by Guido van Rossum:
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1018>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mai
Guido van Rossum added the comment:
Committed revision 57464.
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum added the comment:
Thanks!!
Committed revision 57564.
SocketIO was recently moved to socket.py because that's the only place
that uses it. So I've removed it from io.__all__.
The only other change I applied was related to the isatty check -- you
accidentally chan
Guido van Rossum added the comment:
Committed revision 57570.
I didn't review it though.
--
nosy: +gvanrossum
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Guido van Rossum added the comment:
Committed revision 57574.
--
nosy: +gvanrossum
resolution: -> accepted
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Guido van Rossum added the comment:
Thanks!
Committed revision 57594.
General note: please run Tools/scripts/reindent.py over your files after
editing so I won't have to.
--
nosy: +gvanrossum
resolution: -> accepted
status: open -> closed
___
Guido van Rossum added the comment:
I'ev fixed this slightly differently, by simply changing the *default*
of the newline argument to StringIO to be "\n". This is a good default;
but I see no reason to prevent users from messing with it if they have a
need.
--
no
Guido van Rossum added the comment:
Committed revision 57669.
I have no way to test this so you'll have to watch the buildbot.
However, I didn't include the patch to _fileio.c that prevents closing
fds 0, 1, 2; I think that's the wrong thing to do and if it causes
problems
Guido van Rossum added the comment:
Committed revision 57670.
You will have to watch the buildbots to see if this worked.
--
nosy: +gvanrossum
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://
Guido van Rossum added the comment:
Committed revision 57672.
You'll have to watch the buildbots.
--
nosy: +gvanrossum
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Guido van Rossum added the comment:
r57674.
I'm not sure this is the right fix though...
--
nosy: +gvanrossum
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Guido van Rossum added the comment:
The issue in datetimemodule.c was already fixed.
The fix to timemodule.c is wrong -- when there are non-ASCII characters
in the unicode string, the length of the UTF-8 conversion is not equal
to that of the original Unicode string.
--
nosy
Changes by Guido van Rossum:
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1009>
__
___
Python
Guido van Rossum added the comment:
I tried to run the various demos in Demo/curses/ with the new version.
They all work except for xmas.py. Before your patch, they all ran.
So I cannot apply this yet. (No time to look into it further, alas.)
--
nosy: +gvanrossum
Guido van Rossum added the comment:
I'll defer thinking about this until post-a1.
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Guido van Rossum added the comment:
Is this still relevant? The patch fails applying with quit a bit of
fireworks:
patching file moduleobject.c
Hunk #1 FAILED at 66.
Hunk #2 succeeded at 86 (offset -5 lines).
Hunk #3 FAILED at 115.
Hunk #4 FAILED at 128.
3 out of 4 hunks FAILED -- saving
Guido van Rossum added the comment:
Why are you using _runscript(), which is an internal routine? I've had a
fair amount of success with other invocations, like pdb.run().
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://b
201 - 300 of 5563 matches
Mail list logo
