Which means you cancel a running task but still have to wait for it and check
if it eventually has a result. This is OK for internal use, but highly counter
intuitive for the end-user. And it makes the cancelled status even more
inconsistent, as calling cancel on a running task does not ensure
Aren't you able to catch the cancellation error and retrieve the data from
the inner task's .result()?
On Wed, Jul 31, 2019, 8:00 AM Guido van Rossum wrote:
> I wonder if Nathaniel has something to add? Trio has a different approayto
> cancellation. Of course it is also an entirely new
On Jul 31, 2019, at 06:28, Agustín Scaramuzza
wrote:
>
> Ouch! That's what happens when you don't proof read your emails :S
>
> Replace --verbose with --print_operation, the idea of the snippet was to show
> an example for keyword parameters.
OK, so how does the magic code know that
On Wed, Jul 31, 2019 at 2:06 AM Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:
>
>
> On 31/07/2019 00:35:59, Eric V. Smith wrote:
> >> On Jul 30, 2019, at 11:38 AM, Guido van Rossum
> wrote:
> >>
> > ..
> >
> >> with connect() as stream: # connect() or __enter__() can fail.
Ouch! That's what happens when you don't proof read your emails :S
Replace --verbose with --print_operation, the idea of the snippet was to
show an example for keyword parameters.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe
On 31/07/2019 00:35:59, Eric V. Smith wrote:
On Jul 30, 2019, at 11:38 AM, Guido van Rossum wrote:
..
with connect() as stream: # connect() or __enter__() can fail.
for data in stream: # __next__() can fail
write(data) # write() can fail
This very much
On 30/07/2019 23:37:38, Greg Ewing wrote:
Guido van Rossum wrote:
I'm not sure I understand the desire to catch every possible
exception right where it occurs. I've never felt this need somehow.
This is my feeling too. I can't remember having a need for such
needle-sharp targeting of
