add cell_meta to ExecutionInfo and pass through run_cell#15071
add cell_meta to ExecutionInfo and pass through run_cell#15071erawn wants to merge 4 commits intoipython:mainfrom
Conversation
|
Because the default for cell_meta is already None, I've kept that default and changed the existing instance where the default was an empty dictionary. Btw, using empty dictionaries as default arguments is warned against in the docs so it seemed reasonable to stick with |
rodrigosf672
left a comment
There was a problem hiding this comment.
Thank you so much for these changes, @erawn. The more I understood about them, the more appreciate the value of this contribution.
Non-blocking question: since cell_meta becomes part of the public execution path, do you think it’d be worth adding a brief docstring note about its expected use and structure? Even one sentence might help extension authors discover it. If you think that'd be a good idea, I can address it as a separate issue/PR.
Again, thanks so much for this contribution and for being so open about getting feedback from the Jupyter community. :)
|
Thank you so much for your help! You've made my first IPython pull request a really lovely experience :) Happy to add the docstring—is the most recent change I've made what you had in mind? The docstring for |
This is a PR to propose adding
cell_metatoExecutionInfoso that IPython extensions can utilize it. This PR builds on 1169 which passedcell_metato the kernel, and adds it as an optional field inExecutionInfowhich is then passed torun_cell. Other half on the ipykernel side is hereMy own personal use case (and the one I would imagine most have for this), is building IPython extensions which pair with extended/customized frontend clients. Personally, I've had to do some rather messy hacks in order to run an IPython and JupyterLab extension which can communicate, and for anything more than a prototype it would be valuable to have a way to append information to the execution requests directly that can be seen by extensions. Since
cell_metaalready extends themetadatafield in the Jupyter Messaging protocol, this seemed like the most natural way to go about it.As discussed here when
cell_idwas introduced, there was talk of refactoring into a more generalmetadatafield, but it seems the current decision is to keep bothcell_idandcell_meta. This PR would extend that decision and continue passing cell_meta.I'm interested in feedback on what would be most useful to others or if there are decisions we can make now that support the most flexibility long-term. Continuing on with
cell_metaas I've done here wouldn't introduce any breaking changes, and so seems the most straight forward, but I'm curious what others think. Thanks!