TaskGroup.create_task() aslo should accepteager_start argument I guess.

TaskGroup.create_task() aslo should accepteager_start argument I guess.

yup, it's in I just forgot to add it to the news

How would the loop even know what type task factory was installed so as to raise?

• The segfault is being worked on, so let's assume it will get fixed in time and continue to work on this as if it's fixed. The Tuesday deadline is very close!
• In response to Tin's nice table, that's exactly what I assume. I am okay with the exception: it represent a reality of the current implementation and I don't want to add work before beta 1. We may be able to fix that in a later feature release.
• Thomas: "How would the loop even know what type task factory was installed so as to raise?" -- I'm not sure what this refers to. Maybe Tin's remark "there's no way to use the type system to help"? But I still don't understand it. Maybe it's not important, so I'll ignore it for now.

Assuming the segfault will be fixed, let's just work through adding eager_start to all create_task methods. (We can test with the crux of that fix patched in.)

@graingert Do you need help writing any code? One thing I'd like to ensure is that at leasteager_start=None (even when explicitly given) isnot passed to the task factory, to deal with 3rd party task factories that haven't been updated to support this argument.

It might be possible to come up with a protocol whereby a task factory communicates whicheager_start values it supports (e.g. a function attribute on the factory), but that seems a future extension (we'll hopefully learn during beta whether this is needed).

I strongly disagree with raising an exception in the currently supported loop.create_task(eager_start=True) case.

I strongly disagree with raising an exception in the currently supported loop.create_task(eager_start=True) case.

So what would you have happen if the task factory doesn't support eager starts? This API is a breaking change if lazy task factories nowmust handle this.

Ah I see, yes then an exception in that case is the current behaviour

All commit authors signed the Contributor License Agreement.

Ah I see, yes then an exception in that case is the current behaviour

But by looking at more of the code I just learned that the eagerness is purely implemented by passingTask(..., eager_start=True) so there is no need to have that exception in the table!

There's one bit of behavior that's changed -- not sure if we care (the docs do not mention it): if you explicitly usecreate_task(..., context=None) it will passcontext=None to the task factory, whereas the original code would not pass it. But is anyone passingcontext=None explicitly? Ditto foreager_start=None, though we could say that that's the same asFalse.

I know why the tests fail, will fix in a moment.

LGTM! Thanks!

W00t! Goodnight everyone. Welcome to beta 1.

⚠️⚠️⚠️ Buildbot failure⚠️⚠️⚠️

Hi! The buildbotAMD64 Debian root 3.x (tier-1) has failed when building commit08d7687.

What do you need to do:

1. Don't panic.
2. Checkthe buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/#/builders/345/builds/11228) and take a look at the build logs.
4. Check if the failure is related to this commit (08d7687) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/#/builders/345/builds/11228

Failed tests:

• test_decimal
• test_external_inspection

Failed subtests:

• test_async_remote_stack_trace - test.test_external_inspection.TestGetStackTrace.test_async_remote_stack_trace

Summary of the results of the build (if available):

==

Traceback (most recent call last):  File"/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_external_inspection.py", line269, intest_async_remote_stack_traceself.assertEqual(stack_trace, expected_stack_trace)~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^AssertionError:Lists differ: [[('c[62 chars]y', 10), ('c4', '/tmp/test_python_sp6aoafc/tmp[1293 chars]]]]]] != [[('c[62 chars]y', 11), ('c4', '/tmp/test_python_sp6aoafc/tmp[1308 chars]]]]]]Traceback (most recent call last):  File"/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_external_inspection.py", line269, intest_async_remote_stack_traceself.assertEqual(stack_trace, expected_stack_trace)~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^AssertionError:Lists differ: [[('c[62 chars]y', 10), ('c4', '/tmp/test_python_9w2frcjy/tmp[1293 chars]]]]]] != [[('c[62 chars]y', 11), ('c4', '/tmp/test_python_9w2frcjy/tmp[1308 chars]]]]]]

Thetest_external_inspection failure seems relevant, as some of the sample code covered by test is async code.
Perhaps the test itself needs to be updated?

It's already fixed, here's the issue:#133419