New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jupyter notebook support #2345
Comments
Thanks for offering to work on this! Here are my takes:
It would be better if we could handle those cells. Perhaps we can put support behind an optional extra (like we do for uvloop), so users who don't need it don't have to deal with the extra dependency.
We could add a "Jupyter mode" that leaves trailing semicolons alone, similar in spirit to the existing pyi mode.
What you write sounds like the best solution. It's unfortunate though, since it means the failure will pass silently if there is a bug in the Black parser that makes us unable to parse some valid code. |
Yes, exactly - in nbQA I have the Thanks for your feedback anyway, I'll get to work next week! EDITI might be possible to detect automagics properly, but it'd require running |
One final thing to bring up is cells with multi-line magics, e.g.
"get_ipython().run_line_magic('timeit', 'f(1, 2, 3)')\n" , thus losing the Because this can't be reconstructed exactly, in nbQA I skip processing cells with multi-line magics. Would that be OK here too? EDITAlternatively, the above could simply be transformed to
|
Having looked further into this, it is possible to detect automagics, but they require a running ipython kernel, i.e. if My outstanding question, then, is around multiline magics. Any thoughts on what %timeit f(1, \
2, \
3) ? Thanks |
In that particular case, ideally Black should turn it into Otherwise, we should either just leave multi-line magics alone (as you suggested above) or come up with some safe way to put the backslashes back. |
yeah, depending on the magic, the argument might not be Python code. e.g.
Cool, thanks for your reply, working on a PR |
CC @ryantam626 who maintains https://github.com/ryantam626/jupyterlab_code_formatter (which handles many of these issues already - but only in jupyterlab). |
Thanks @mlucool I've had a look at the source code, but it looks like magics are detected with regular expressions, which feels brittle. if True:
%time 2+2 , ran the jupyter code formatter, and got
I've reported this bug to |
Unfortunately, there doesn't seem to be a non-hacky way of capturing the return code: https://stackoverflow.com/a/35168666/4451315 So for now I'll leave automagics out - I've made a first draft here #2357 , if anyone following along has any test cases I hadn't thought of to suggest, I'd be extremely happy to see them |
Hi @JelleZijlstra - question on the design: if you have the jupyter dependencies installed, then if you run
then should
? At the moment, the PR I opened does the former, but I think the latter might be more desirable, as then an error message can be thrown if the additional dependencies aren't found UPDATEIn the end I've gone with not running on notebooks by default. To run on notebooks, users should pass |
I feel like we should format ipynb files by default once we support them, so the default behavior of I'm curious if other maintainers have a different opinion. |
Makes sense, thanks - I've reverted to that behaviour |
I also prefer the default if the support is there. Less CLI args the better imo (+ black's original goals of not being configurable) ... |
OK, done. I'm also raising a warning if |
@MarcoGorelli Naive question: is a cell's last line of code supposed to end with a newline? (hence with an extra empty line at the end of the cell) |
Thanks @jucor , that's kind of you! I wouldn't expect there to be a trailing newline in every single cell - if you agree, I'd suggest reporting this to vscode if they do something different. I haven't had a look at what they do, but I'd have thought they could just use |
Thanks for the fast and precise answer @MarcoGorelli ! I completely agree with you, the trailing newline in the cell surprised me :) It seems that VSCode dumps the content of the cell to a tempfile then applies black to that tempfile then reads it into the cell. Therefore black formats this cell like a single file, with (rightly for a file!) a newline at the end :/ |
Hmm, so I presume they don't handle "silent mode" or magics? No idea how to make a report more salient, sorry - perhaps opening a pull request? |
I've spent some time digging in the internals of vscode, vscode-python, and vscode-jupyter, see if I could make a PR. I can confirm that for all formatters it supports (autopep8, yapf, black), vscode always format notebook cells by simply dumping the content of the cell (not the JSON, mind you!) to a tempfile then calling the formatter on the command line on that file. Hence the trailing "\n". Any request or PR to do otherwise for black (e.g. properly calling However, it should be easy to modify so it calls |
Possibly, but I really think this should be fixed in vscode. I'm not a |
Actually you're right. The exact same problem happens when vscode calls autopep8 and yapf. |
Hi @MarcoGorelli
|
I'd suggest C. use In my opinion, Just my opinion though |
That'd be the cleanest, but would require to change the whole logic of
VSCode and to call a Python function from VSCode's typescript codebase.
Seems like a lot of work :)
Is there a way to call back.format_cell on a file specified at the CLI? If
so then we re golden :)
…On Tue, 12 Oct 2021, 10:38 Marco Edward Gorelli, ***@***.***> wrote:
I'd suggest
C. use black.format_cell directly
In my opinion, black need not add extra complexity just for the sake of a
single IDE
Just my opinion though
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2345 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFBERJDFBLMC4Y6LGUTTQ3UGP6ZZANCNFSM47DDSS2Q>
.
|
#1814 was closed, with the message:
I'd be quite interested in seeing
black
support Jupyter Notebooks natively. Indeed, I wrote nbQA for the purpose of running this and other tools on notebooks, but if notebooks could be handled by the tools themselves, that'd be even better.A few questions / discussion points before I begin:
ast.parse
would throw a syntax error (e.g. any cell containing IPython magics) - should they be handled (as is done in nbQA, viaIPython
'sTransformerManager().transform_cell()
) or ignored? Note that the former would requireIPython
as a dependencyblack
would remove them. In nbQA, I preserve these trailing semicolons by adding them back afterblack
has removed them. Would it be OK to do that here too?pwd
is fine in a Jupyter Notebook cell, but it's not valid Python. Automagics can only be detected with a running IPython kernel. In nbQA I deal with this by skipping over cells whose content can't be parsed neitherast.parse
norTransformerManager().transform_cell()
The text was updated successfully, but these errors were encountered: