Does this spell doom for the 3.14 change????@graingert

I don't think so, a new kwargcontext was addedand passed in asyncio.Runner in 3.11 so there's precedent for this sort of change. Foreager_start we're adding it but not passing it anywhere so it's not breaking any existing code. Forname it's being passed and added.

If we decide passingname is breaking (and passingcontext was also breaking and we agree it shouldn't have been added) we can popname from the kwargs inBaseEventLoop.create_task and use a flag and deprecation cycle to add it back like@serhiy-storchaka suggested. The feature for the eager_start is still valid

So it just shouldn’t have been backported. Sorry.

somehow I can’t find the issue suggesting the revert.

See#133745. That argument applies to 3.14 too.In fact we broke the “name, context may be positional” for create task?

Ah yes definitely! I'll get a PR for 3.14 to fix the positional behavior for name and context ah no they were keyword only

name andcontext always were keyword only.

But we broke explicitcontext=None.create_task(coro, context=None) did not passcontext to the task factory.

Notice that several people have implemented workarounds since then so we need to ensure we preserve both behaviors to not break the people that have adapted. For example:beeware/toga#3395

Looks like we have more work to do -- 3.13.4 must support the workarounds that people have already made for 3.13.3.

FWIW as one of the people who made a workaround, we just followed the documentation and passed through**kwargs, which is compatible with a simple revert;beeware/toga have also done it this way. As well as being the new documented contract, this is also the simplest way to remain compatible with Python 3.12 and earlier, so hopefully most people will have done the same.

Thanks@alicederyn, that's very helpful.

@graingert Are you going to update this PR to not break the workaround described by@alicederyn ?

Does a plain revert break the workaround?

Does a plain revert break the workaround?

I think so. Pre-revert (but only in 3.13.3), you could have a "private" keyword parameter passed to create_task() that's passed on to your factory (assuming you have control over the factory and your factory accepts this private keyword). So I think the various create_task() methods should (in addition to name= and context=) grow a new**kwargs that just is passed on to the factory or task (causing an error if it's not expected).

It's possible that that fix also models the improved version for 3.14b2 (which should pop name andcancel context if they're None, IIUC).

Ah right, that's a better option!

I'm not sure about this:

and cancel if they're None, IIUC).

Do you meanTask.cancel(), or abort withRuntimeError, orcoro.close(), or something else?

Sorry, "and cancel" should have been "and context". Will fix in the original.

Do you want to always pop name in 3.13.4?

So, passing name= through kwargs to the factory must be a feature that factories must support to be compatible with 3.13.3 (but not later versions of 3.13), and to be compatible with 3.14b1+. 3.13.4+ must revert to the lame setname call to send the factory the name (a very old hack to be compatible with earlier versions of uvloop IIRC), but for 3.14b2 and everything after we require factories to support passing name= via **kwargs, and won't do the setname call any more. Right?

Do you want to always pop name in 3.13.4?

I think so, since pre-3.13.3 factories may not support any keywords (other than and empty dict) and IIUC there's no way to tell if a factory supports that or requires setname, and I don't want to introduce a new API so we could ask a task factory about this.

Ok I opened up a draft here:#133948

the news fragment is going to be fun, I've left it blank for now