On Wed, Jun 23 2021 at 05:16:00 PM -0000, Mark Gordon
<[email protected]> wrote:
That's a feature :) Perhaps we should add an example to the docs.
What do you view as the point of the copy semantics, then?
Are you asking why the context is using immutable data-structures
internally, in the first place? Please read the PEP, it explains that
in great detail. Short answer: performance; it has nothing to do with
*what* is stored in the context. It can store mutable objects, that's
totally OK for aggregating metrics, for example.
There's not much wrong about this approach for simple coroutines.
But
if a coroutine runs its own tasks or code that forks the context
inside, you won't see those changes in your context.
I thought you were against this usage pattern anyway. Not sure what
this has to do with the proposed API change.
In other words,
the hack you propose will work for some cases, and fail for others.
It seems like you are assuming a purpose to this API that I did not
intend. It really is just so you can change a context that a task is
running within without creating a new task. It's really just to be an
analog of Context.run.
I'm +1 to add a 'context' keyword-argument to 'asyncio.create_task()'.
It will still be copied. I believe I've explained *why* the copy is
still necessary in this thread.
Yury
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/HAGHPOGYTVLXD6T6TLWZHTCC2TNJI37B/
Code of Conduct: http://python.org/psf/codeofconduct/
