Even if the documentation says, don't change your code while running,
it's not good if the user does it and then code gets overwritten.
It's especially painfull when you restructure code as the whole counting
gets confused and in the end code gets changed in other cells, too :-(
So, I add here some logic that checks that the unformatted code is the
same as found before running the cell. If not, for w/e reason, don't
set the code cell to the black formatted code.
It would be better, if the user would get any notification in case (like
a warning logging event or some tooltip or some additional output), but
my knowledge of the Javascript Python interaction is not good enough to
do it right now. It might be best to do the formatting on frontend side,
but well, so let's integrate black into Javascript frontend another time
:-o
Nonetheless, this PR should protect the integrity of the
jupyter notebook what's more important and still allow an interactive
workflow :-)
Even if the documentation says, don't change your code while running, it's not good if the user does it and then code gets overwritten. It's especially painfull when you restructure code as the whole counting gets confused and in the end code gets changed in other cells, too :-(
So, I add here some logic that checks that the unformatted code is the same as found before running the cell. If not, for w/e reason, don't set the code cell to the black formatted code.
It would be better, if the user would get any notification in case (like a warning logging event or some tooltip or some additional output), but my knowledge of the Javascript Python interaction is not good enough to do it right now. It might be best to do the formatting on frontend side, but well, so let's integrate black into Javascript frontend another time :-o
Nonetheless, this PR should protect the integrity of the jupyter notebook what's more important and still allow an interactive workflow :-)