[issue33125] Windows 10 ARM64 platform support

Change by Guido van Rossum : -- nosy: -Guido.van.Rossum ___ Python tracker <https://bugs.python.org/issue33125> ___ ___ Python-bugs-list mailing list Unsub

[issue41370] PEP 585 and ForwardRef

Guido van Rossum added the comment: I asked for a brief example that explains your issue to me. Instead you sent me links to production code and patches to it. Sorry, but that doesn't help me understand your problem. Is there really no way that you can write a little story that goes

[issue41370] PEP 585 and ForwardRef

Guido van Rossum added the comment: When PEP 585 was discussed and implemented we did not expect people to care as much about runtime types as they did. I already explained that making list['Node'] incorporate a ForwardRef instance is unrealistic (we'd have to reimplement

[issue41370] PEP 585 and ForwardRef

Guido van Rossum added the comment: Ah, I see the issue. I stepped through get_type_hints() using pdb, and it does have a special case for when it encounters a string: it wraps it in a ForwardRef and proceeds from there: https://github.com/python/cpython/blob

[issue41370] PEP 585 and ForwardRef

Guido van Rossum added the comment: Here's a patch that doesn't do it right but illustrates the point: diff --git a/Lib/typing.py b/Lib/typing.py index 972b8ba24b..4616db60c3 100644 --- a/Lib/typing.py +++ b/Lib/typing.py @@ -1807,6 +1807,12 @@ def get_type_hints(obj, globalns=Non

[issue46491] typing: allow Annotated in outermost scope

Guido van Rossum added the comment: But it *is* a bugfix. -- ___ Python tracker <https://bugs.python.org/issue46491> ___ ___ Python-bugs-list mailing list Unsub

[issue46491] typing: allow Annotated in outermost scope

Guido van Rossum added the comment: Well that's *always* a problem right? If you take that to the extreme we wouldn't need bugfix releases. :-) Apart from some examples in the 3.5-3.6 timeframe, what makes you think that *this* fix *specifically* is going to make more people unhap

[issue46491] typing: allow Annotated in outermost scope

Guido van Rossum added the comment: Yeah, there are no perfect solutions. Please let it go. -- ___ Python tracker <https://bugs.python.org/issue46491> ___ ___

[issue43853] [sqlite3] Improve sqlite3_value_text() error handling

Guido van Rossum added the comment: New changeset 3eb3b4f270757f66c7fb6dcf5afa416ee1582a4b by Erlend Egeberg Aasland in branch 'main': bpo-43853: Expand test suite for SQLite UDF's (GH-27642) https://github.com/python/cpython/commit/3eb3b4f270757f66c7fb6dcf5afa416ee1582a4b

[issue46539] typing: forward references don't understand special type forms

Guido van Rossum added the comment: I wonder if this is at all similar to bpo-41370. -- ___ Python tracker <https://bugs.python.org/issue46539> ___ ___ Pytho

[issue46539] typing: forward references don't understand special type forms

Guido van Rossum added the comment: Agree it's not the same issue, but there's similarity -- both are due to putting a stringized annotation (presumably a forward ref) somewhere inside another construct. whether it's list["N"] o

[issue46539] typing: forward references don't understand special type forms

Guido van Rossum added the comment: New changeset ced50051bb752a7c1e616f4b0c001f37f0354f32 by Gregory Beauregard in branch 'main': bpo-46539: Pass status of special typeforms to forward references (GH-30926) https://github.com/python/cpython/commit/ced50051bb752a7c1e616f4b0c001f

[issue46552] typing: get_type_hints can't handle stringified annotations with leading spaces

Guido van Rossum added the comment: We should not accept leading spaces.-- --Guido (mobile) -- ___ Python tracker <https://bugs.python.org/issue46552> ___ ___

[issue44791] Substitution of ParamSpec in Concatenate

Guido van Rossum added the comment: Before you start supporting things that contradict PEP 612 this should be discussed on typing-sig (or in the python/typing tracker). Honestly I'd feel more comfortable if there was agreement on typing-sig with your previous PRs in this issue as well

[issue46553] typing: get_type_hints on stringified lone ClassVar raises TypeError

Guido van Rossum added the comment: It seems acceptable to mypy. I'm not sure I like the agenda of "moving dataclasses to using typing.py introspection tools". -- ___ Python tracker <https://bugs.pyt

[issue46552] typing: get_type_hints can't handle stringified annotations with leading spaces

Change by Guido van Rossum : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue46553] typing: get_type_hints on stringified lone ClassVar raises TypeError

Guido van Rossum added the comment: Please just don't go there. I beg you. It's not worth it. -- ___ Python tracker <https://bugs.python.org/issue46553> ___ __

[issue46553] typing: get_type_hints on stringified lone ClassVar raises TypeError

Guido van Rossum added the comment: I To be clear: I am okay with this patch, just not with making dataclasses import typing. -- --Guido (mobile) -- ___ Python tracker <https://bugs.python.org/issue46

[issue46530] `'thread_time'` is missing from `test_get_clock_info`

Guido van Rossum added the comment: New changeset c27a33132be101e246ae2584f1826477357138d6 by Nikita Sobolev in branch 'main': bpo-46530: add `"thread_time"` to `test_time.test_get_clock_info` (#30913) https://github.com/python/cpython/commit/c27a33132be101e246ae

[issue46553] typing: get_type_hints on stringified lone ClassVar raises TypeError

Guido van Rossum added the comment: New changeset 5445e173e76ec792358082caf660fbdc846c64b2 by Gregory Beauregard in branch 'main': bpo-46553: allow bare typing.ClassVar annotations (#30983) https://github.com/python/cpython/commit/5445e173e76ec792358082caf660fb

[issue26552] Failing ensure_future still creates a Task

Guido van Rossum added the comment: So I just realized that the OP's description is slightly misleading. (Their code is spot on though!) The code does not create an unwaited-for *task*, assuming that "task" refers to the asyncio.Task class. What is created is a *coroutine

[issue26552] Failing ensure_future still creates a Task

Guido van Rossum added the comment: New changeset 24cc6411adbfeecd8901f1ea50caa414c908 by Kumar Aditya in branch 'main': bpo-26552: Fixed case where failing `asyncio.ensure_future` did not close the coroutine (#30288) https://github.com/python/cpyt

[issue26552] Failing ensure_future still creates a Task

Guido van Rossum added the comment: Thanks Kumar for the fix! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue26552] Failing ensure_future still creates a Task

Guido van Rossum added the comment: New changeset a5451c96a14ac0c3ee7cef7b5c52ab1d783ec613 by Kumar Aditya in branch '3.10': bpo-26552: Fixed case where failing `asyncio.ensure_future` did not close the coroutine (#30288) (#31003) https://github.com/python/cpyt

[issue46571] Strange `@typing.no_type_check` behavior for class variables

Guido van Rossum added the comment: @no_type_check (introduced by PEP 484) is intended for static checkers, to signal to them that they shouldn't check the given function or class. I don't think PEP 484 specifies its runtime effect -- arguably get_type_hints() could just ignore it

[issue46571] Strange `@typing.no_type_check` behavior for class variables

Guido van Rossum added the comment: I agree that Jelle's proposal (Nikita's #2) looks best *if* we can implement it. How do we ensure that class A: ... @no_type_check class B: AA = A class C: ... ... suppresses annotations in B and C bu

[issue46571] Strange `@typing.no_type_check` behavior for class variables

Guido van Rossum added the comment: Okay, somebody can submit a PR! -- ___ Python tracker <https://bugs.python.org/issue46571> ___ ___ Python-bugs-list mailin

[issue46372] int/float specializations should mutate the LHS in-place when possible

Guido van Rossum added the comment: Since we decided to wait on the int operations while longobject.c is being refactored (https://github.com/faster-cpython/ideas/issues/245), can you clarify whether the speedup reported is from code where it is implemented only for floats, or is it from a

[issue45711] Simplify the interpreter's (type, val, tb) exception representation

Guido van Rossum added the comment: Time to insist on directly communicating with the Cython team (esp. @scoder) and broker some kind of compromise. -- ___ Python tracker <https://bugs.python.org/issue45

[issue44359] test_ftplib.test_makeport() fails as "env changes" if a socket operation times out in a thread: TimeoutError is not catched

Guido van Rossum added the comment: Maybe it's time to actually try to fix this test rather than just complaining about it? Surely *somebody* here has an idea? Else maybe we need to just disable it. -- nosy: +gvanrossum ___ Python tracker &

[issue46414] Add typing.reveal_type

Guido van Rossum added the comment: New changeset abcc3d75f6e570519cb37c62130a2295c6928bff by Jelle Zijlstra in branch 'main': bpo-46414: Add typing.reveal_type (#30646) https://github.com/python/cpython/commit/abcc3d75f6e570519cb37c62130a22

[issue46608] Exclude marshalled-frozen data if deep-freezing to save 300 KB space

Change by Guido van Rossum : -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/issue46608> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44796] Add __parameters__ and __getitem__ in TypeVar and ParamSpec

Guido van Rossum added the comment: I don't think that changing list[None] to list[NoneType] in the output is an improvement. I do appreciate the reduction in C code though! -- ___ Python tracker <https://bugs.python.org/is

[issue45380] help() appears confused about the module of typing.Annotated

Guido van Rossum added the comment: It looks like __metadata__ was *meant* to be a public attribute, but somehow overseen when the PEP and docs were written. :-( I don't know anything about this class, really. -- ___ Python tracker &

[issue46608] Exclude marshalled-frozen data if deep-freezing to save 300 KB space

Guido van Rossum added the comment: New changeset 9d4161a60ca8b470148ffd6c73e3110a0aa6d66f by Kumar Aditya in branch 'main': bpo-46608: Fix argument parsing in freeze_modules.py (GH-31131) https://github.com/python/cpython/commit/9d4161a60ca8b470148ffd6c73e311

[issue38941] xml.etree.ElementTree.Element inconsistent warning for bool

Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <https://bugs.python.org/issue38941> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46642] typing: tested TypeVar instance subclass TypeError is incidental

Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <https://bugs.python.org/issue46642> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46661] Duplicat deprecation warnings in docs for asyncio

New submission from Guido van Rossum : I found that several asyncio function descriptions, e.g. gather, have a duplicate deprecation notice like this: .. deprecated-removed:: 3.8 3.10 The ``loop`` parameter. This function has been implicitly getting the current running loop

[issue46644] typing: remove callable() check from typing._type_check

Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <https://bugs.python.org/issue46644> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46661] Duplicat deprecation warnings in docs for asyncio

Guido van Rossum added the comment: Kumar are you interested in fixing this? -- ___ Python tracker <https://bugs.python.org/issue46661> ___ ___ Python-bug

[issue46655] typing.TypeAlias is not in the list of allowed plain _SpecialForm typeforms

Guido van Rossum added the comment: Looks like the more likely use case would be PEP 563: from __future__ import annotations from typing import TypeAlias, get_type_hints import typing class C: a: TypeAlias = int print(get_type_hints(C)) This prints Traceback (most recent call last

[issue46655] typing.TypeAlias is not in the list of allowed plain _SpecialForm typeforms

Guido van Rossum added the comment: New changeset 77b025be4a4cd5a3bfc1b1af560cc57e8e956c98 by Gregory Beauregard in branch 'main': bpo-46655: allow stringized TypeAlias with get_type_hints (GH-31156) https://github.com/python/cpython/commit/77b025be4a4cd5a3bfc1b1af560cc5

[issue46611] Improve coverage of `__instancecheck__` and `__subclasscheck__` methods in `typing.py`

Guido van Rossum added the comment: New changeset 067c03bf40d13393209f0138fa9c4d5980c4ff8a by Nikita Sobolev in branch 'main': bpo-46611: add coverage to instance and class checks in `typing.py` (GH-31078) https://github.com/python/cpython/commit/067c03bf40d13393209f0138fa9c4d

[issue46589] Improve documentation for typing._GenericAlias

Guido van Rossum added the comment: New changeset a335d98f19b7fa66159d12932cc9a05eb2d8395f by Matthew Rahtz in branch 'main': bpo-46589: Improve documentation for typing._GenericAlias (GH-31026) https://github.com/python/cpython/commit/a335d98f19b7fa66159d12932cc9a0

[issue44796] Add __parameters__ and __getitem__ in TypeVar and ParamSpec

Guido van Rossum added the comment: Super subtle stuff. Tonight I do not have time to really dive into this, but I think Serhiy is on to something. KJ or Jelle, do you have the guts to dive in here? -- ___ Python tracker <https://bugs.python.

[issue46655] typing.TypeAlias is not in the list of allowed plain _SpecialForm typeforms

Guido van Rossum added the comment: New changeset e2eeffefed32bb8c47c09bdd94e27a4e949894ef by Gregory Beauregard in branch '3.10': [3.10] bpo-46655: allow stringized TypeAlias with get_type_hints (GH-31156). (#31175) https://github.com/python/cpyt

[issue12029] Allow catching virtual subclasses in except clauses

Guido van Rossum added the comment: Fixing the version field. Since it's a feature, this could not go into any version before 3.11. Maybe Irit can look through the discussion and patch and see if there's value to doing this? (Feel free to decline!) -- nosy: +iritkatrie

[issue46534] Implementing PEP 673 (Self type)

Guido van Rossum added the comment: New changeset 7ba1cc8049fbcb94ac039ab02522f78177130588 by James Hilton-Balfe in branch 'main': bpo-46534: Implement PEP 673 Self in typing.py (GH-30924) https://github.com/python/cpython/commit/7ba1cc8049fbcb94ac039ab02522f7

[issue12029] Allow catching virtual subclasses in except clauses

Guido van Rossum added the comment: Thanks you. I think it's reasonable to reject the feature request and instead update the docs, so let's do that. -- ___ Python tracker <https://bugs.python.o

[issue46475] typing.Never and typing.assert_never

Guido van Rossum added the comment: New changeset 243436f3779c1e7bed1fd4b23d5a8ec5eff40699 by Jelle Zijlstra in branch 'main': bpo-46475: Add typing.Never and typing.assert_never (GH-30842) https://github.com/python/cpython/commit/243436f3779c1e7bed1fd4b23d5a8e

[issue44289] tarfile.is_tarfile() and tarfile.open() when used with file object may cause tarfile operations to fail

Guido van Rossum added the comment: New changeset 128ab092cad984b73a117f58fa0e9b4105051a04 by Andrzej Mateja in branch 'main': bpo-44289: Keep argument file object's current position in tarfile.is_tarfile (GH-26488) https://github.com/python

[issue46430] intern strings in deepfrozen modules

Guido van Rossum added the comment: New changeset c0a5ebeb1239020f2ecc199053bb1a70d78841a1 by Kumar Aditya in branch 'main': bpo-46430: Intern strings in deep-frozen modules (GH-30683) https://github.com/python/cpython/commit/c0a5ebeb1239020f2ecc199053bb1a

[issue46430] intern strings in deepfrozen modules

Guido van Rossum added the comment: We discussed that and found that a lot of errors are ignored during interning anyway. But it's not too late to change if you want to (sending a PR would probably be quicker than arguing :-). -- ___ P

[issue46066] Deprecate keyword args syntax for TypedDict definition

Guido van Rossum added the comment: Go ahead and send a or to deprecate it.-- --Guido (mobile) -- ___ Python tracker <https://bugs.python.org/issue46

[issue46066] Deprecate keyword args syntax for TypedDict definition

Guido van Rossum added the comment: "PR" -- ___ Python tracker <https://bugs.python.org/issue46066> ___ ___ Python-bugs-list mailing list Uns

[issue46725] Unpacking without parentheses is allowed since 3.9

Guido van Rossum added the comment: Let's just document it for 3.11. -- ___ Python tracker <https://bugs.python.org/issue46725> ___ ___ Python-bugs-list m

[issue46708] test_asyncio: test_sock_client_fail() changes asyncio.events._event_loop_policy

Guido van Rossum added the comment: Heh, I just ran into this for test_taskgroups as well. (Alas, I had debugged and fixed it independently before I found this. :-) -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue46

[issue46661] Duplicate deprecation warnings in docs for asyncio

Change by Guido van Rossum : -- title: Duplicat deprecation warnings in docs for asyncio -> Duplicate deprecation warnings in docs for asyncio ___ Python tracker <https://bugs.python.org/issu

[issue46333] ForwardRef.__eq__ does not respect module parameter

Guido van Rossum added the comment: New changeset b70690bb37cc4bac695051484734eede0c1f9ada by aha79 in branch 'main': bpo-46333: include `module` in `ForwardRef.__repr__` (#31283) https://github.com/python/cpython/commit/b70690bb37cc4bac695051484734ee

[issue46729] Better str() for BaseExceptionGroup

Guido van Rossum added the comment: Should it show the number of immediate subexceptions (i.e., len(eg.exceptions)) or the number of leaf exceptions? I'd be happy with the former (since that's what EdgeDb's MultiError does), which would not require adding an extra fie

[issue46743] Enable usage of object.__orig_class__ in __init__

Guido van Rossum added the comment: In the early days the design and implementation were changed so many times, your question (why was it changed) is unanswerable. I do not actually understand your description of your problem -- you mention so many dunders that it obscures your use case

[issue46743] Enable usage of object.__orig_class__ in __init__

Guido van Rossum added the comment: I'm sorry, that's not a small example that I can follow, and I have no idea why you are doing all those things. I fear that if you cannot be more articulate this will remain unfixed. -- ___ Pyth

[issue46743] Enable usage of object.__orig_class__ in __init__

Guido van Rossum added the comment: Thanks for the small example, I understand what you are trying to do now. I don't think it's possible in general, since you are blindly instantiating the type (self.__orig_class__.__args__[0]) without arguments. That doesn't work for all t

[issue46743] Enable usage of object.__orig_class__ in __init__

Guido van Rossum added the comment: > On the general class instanciation point would there be anything wrong with > just adding a big red warning saying (on the non-existent) docs for these > classes that they don't follow normal class initization or is this too > insignif

[issue46743] Enable usage of object.__orig_class__ in __init__

Guido van Rossum added the comment: Yeah, that should erase the type, not have special semantics. -- ___ Python tracker <https://bugs.python.org/issue46

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

New submission from Guido van Rossum : After some conversations with Yury, and encouraged by the SC's approval of PEP 654, I am proposing to add a new class, asyncio.TaskGroup, which introduces structured concurrency similar to nurseries in Trio. I started with EdgeDb's

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

Change by Guido van Rossum : -- keywords: +patch pull_requests: +29493 pull_request: https://github.com/python/cpython/pull/31270 ___ Python tracker <https://bugs.python.org/issue46

[issue46754] Improve Python Language Reference based on [Köhl 2020]

New submission from Guido van Rossum : In https://arxiv.org/pdf/2109.03139.pdf ("M Köhl, An Executable Structural Operational Formal Semantics for Python, Master Thesis 2020 Saarland University) there are some observations on cases where the Language Reference (referred to as PL

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

Guido van Rossum added the comment: New changeset 602630ac1855e38ef06361c68f6e216375a06180 by Guido van Rossum in branch 'main': bpo-46752: Add TaskGroup; add Task..cancelled(),.uncancel() (GH-31270) https://github.com/python/cpython/commit/602630ac1855e38ef06361c68f6e21

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

Guido van Rossum added the comment: Remaining TODO list: - Add a test showing the need for the .uncancel() call in __aexit__() (currently on line 97). Dropping that line does not cause any tests to fail. - Ensure the taskgroup tests are run with the C and Python Task implementations

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

Guido van Rossum added the comment: @dhalbert, it's probably better to file a new issue if you want changes to gather(). Although I suppose that if we want to deemphasize it, we shouldn't be adding new features to it. My own new feature idea would be to have it wait for all task

[issue46771] Add some form of cancel scopes

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

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

Guido van Rossum added the comment: I've created a separate issue for cancel scopes: bpo-46771. -- ___ Python tracker <https://bugs.python.org/is

[issue46771] Add some form of cancel scopes

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

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

Change by Guido van Rossum : -- nosy: +dhalbert ___ Python tracker <https://bugs.python.org/issue46752> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46771] Add some form of cancel scopes

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

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

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

[issue46771] Add some form of cancel scopes

Change by Guido van Rossum : -- nosy: +tinchester ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46771] Add some form of cancel scopes

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

[issue46771] Add some form of cancel scopes

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

[issue46771] Add some form of cancel scopes

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

[issue46769] Improve documentation for `typing.TypeVar`

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

[issue46771] Add some form of cancel scopes

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

[issue46771] Add some form of cancel scopes

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

[issue46771] Add some form of cancel scopes

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

[issue46771] Add some form of cancel scopes

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

[issue46771] Add some form of cancel scopes

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

[issue46771] Add some form of cancel scopes

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

[issue46771] Add some form of cancel scopes

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

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

Change by Guido van Rossum : -- pull_requests: +29541 pull_request: https://github.com/python/cpython/pull/31398 ___ Python tracker <https://bugs.python.org/issue46

[issue46771] Add some form of cancel scopes

Change by Guido van Rossum : -- pull_requests: +29542 pull_request: https://github.com/python/cpython/pull/31398 ___ Python tracker <https://bugs.python.org/issue46

[issue46771] Add some form of cancel scopes

Guido van Rossum added the comment: +1 on both aspects of the plan. -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailin

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

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

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

Change by Guido van Rossum : -- pull_requests: +29551 pull_request: https://github.com/python/cpython/pull/31411 ___ Python tracker <https://bugs.python.org/issue46

[issue46725] Unpacking without parentheses is allowed since 3.9

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

[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.

Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue45390> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46771] Add some form of cancel scopes

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

[issue46771] Add some form of cancel scopes

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

[issue46771] Add some form of cancel scopes

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

[issue46771] Add some form of cancel scopes

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

<    1   2   3   4   5   6   7   8   9   10   >