You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Part context manager is in charge of sending the final reduce message. But the message
structure is hardcoded; there's no way for the user of Part to specify additional data.
We need to give the user more control over the reduce message. Two options so far:
1. pass data into Part as an argument
msg = {'custom': 'hi'}
with Part(..., reduce_message=msg)
pass
This has the advantage of being straighforward to understand and a simple implementation.
The downside is that we're forcing the user to construct the message before the context block.
It would not allow for constructing the message within the block.
My hunch is that this would be fine for most use cases and probably where we should start.
2. send data from the inner block
With some context manager tricks, it is possible for the inner block and the context manager to communicate using yield and gen.send. The example below proves it can be done - but the complexity and obscurity of this approach might be too much.
@contextmanagerdefblock():
print('before')
msg=yield# wait for a value to be sentprint(f'the inner block sent me {msg}')
yield# run remainder of inner blockprint('after')
# Have to instantiate the context manager separate from the with statement# `with block() as context` will not workcontext=block()
withcontext:
print('inside')
msg= {'custom': 42}
# the inner block MUST send something or we get# a RuntimeError: generator didn't stopcontext.gen.send(msg)
print('still inside the block')
which prints
before
inside
the inner block sent me 42
still inside the block
after
cc @dnomadb@vincentsarago and @sgillies - this context manager / generator hack is a kind of crazy but thought you might enjoy it :-)
The text was updated successfully, but these errors were encountered:
per chat, while the basic @contextmanager decorator pattern is nice, option 2 above takes this a bit too far into obscurity. We're not confident that we fully understand the underlying concepts fully enough which is a no-go.
The
Part
context manager is in charge of sending the finalreduce
message. But the messagestructure is hardcoded; there's no way for the user of
Part
to specify additional data.We need to give the user more control over the reduce message. Two options so far:
1. pass data into
Part
as an argumentThis has the advantage of being straighforward to understand and a simple implementation.
The downside is that we're forcing the user to construct the message before the context block.
It would not allow for constructing the message within the block.
My hunch is that this would be fine for most use cases and probably where we should start.
2. send data from the inner block
With some context manager tricks, it is possible for the inner block and the context manager to communicate using
yield
andgen.send
. The example below proves it can be done - but the complexity and obscurity of this approach might be too much.which prints
cc @dnomadb @vincentsarago and @sgillies - this context manager / generator hack is a kind of crazy but thought you might enjoy it :-)
The text was updated successfully, but these errors were encountered: