Extend argument handling of do_execute with cell metadata #1169
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Enhances the
do_execute
method by allowing an optionalcell_meta
parameter, which represents cell metadata. This addition aligns with the Jupyter messaging protocol on metadata, which acknowledges the potential use of metadata in various message types.Although
metadata
may not be often used, the capability to handle metadata withindo_execute
can expand the kernel's flexibility, especially in scenarios involving complex interactions or custom extensions, as detailed in the jupyter_client docs.A noteable use case is in the development of Python wrapper kernels, where additional information might be passed via metadata to influence execution behavior, provide additional context, or interact with external services.
Changes:
do_execute
signature to include an optional metadata parameterexecute_request
to extract and pass down cell metadata todo_execute
_accepts_cell_id
to_accepts_parameters
for broader parameter checks, which in turn seemly created nice flow inexecute_request
.It seemed bold requesting to replace
cell_id
withmetadata
despite one is derived from the other. However,_accepts_parameters
enables flexible handling of these optional parameters, thus somewhat ensuring backward compatibility. A minor concern might involve the imports of_accepts_cell_id
, which has been removed/replaced, but can be reintegrated if necessary.Thanks