Are you looking for
ProcessPoolExecutor(mp_context=multiprocessing.get_context("fork"))
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-i
What should happen if the context manager attempts to suppress a raised
exception? In cases where you applied the context manager to an entire line,
e.g.
data = fail() with contextlib.suppress(Exception)
Then it would make sense to treat it like
with contextlib.suppress(Exception):
data =
Looks like a separate issue to me. That issue can be fixed by updating the
Python implementation of WeakKeyDictioary.
The fix for the WeakKeyDictionary issue I mentioned and the Ephemeron primitive
(as Sebastian identified it) are equivalant (you can implement one from the
other) and cannot be
Proposal:
Have a weakref.link (not at all attached to the naming) primitive that allows
one to keep object A alive while object B is alive. This would be functionally
similar to adding A as an attribute of B from the GC's perspective without
making any assumptions about what attributes are avai
I've read the PEP and understand what's implemented. However there is pretty
limited discussion about what the design constraints were and what
intended/recommended usage would look like. I'll answer my own question:
1. If all we wanted was a version of TLS that worked in an analogous way
exten
> 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?
> 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
Yury Selivanov wrote:
> On Mon, Jun 21, 2021 at 7:20 PM Mark Gordon msg...@gmail.com wrote:
> > Yeah, it would indeed inherit the copy. We could, theoretically, make
> > asyncio.Task accept context objects and not copy them, but what would
> > that
> > give us?
> >
> Yeah, it would indeed inherit the copy. We could, theoretically, make
> asyncio.Task accept context objects and not copy them, but what would that
> give us?
My main thinking was to just be similar to the closest synchronous analog I'm
aware of, contextvars.Context.run. I would think an explana
With normal synchronous code you can use `contextvars.Context.run()` to change
what context code is executing within. However, there is no analagous concept
for asyncio code. I'm proposing something similar, for example:
coro = foo()
my_context = convextvars.Context()
await asyncio.run_in_contex