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
We use splitlines() on probable multi-line blocks for nicer ipynb files. But there is a small ambiguity, in that 0 or 1 trailing newlines produce identical output. The only place this really matters is multiple sequential stdout messages.
For instance, run a notebook with the following cell:
Fix %notebook magic, etc. nbformat unicode tests and fixes.
* json.writes always gives unicode, so that `current.writes` can be trusted to give the same interface
* setup base TestCase for nbformat tests, to consolidate code, and better test both file formats
* add tests for reading/writing to files
* allow `name` as kwarg to new_notebook to avoid unnecessary breakage of previous API.
* remove fallback to xml, which would hide corrupt notebook files behind a nonsensical 'xml unsupported' message.
Closesipython#1545, ipython#1487.
We use
splitlines()
on probable multi-line blocks for nicer ipynb files. But there is a small ambiguity, in that 0 or 1 trailing newlines produce identical output. The only place this really matters is multiple sequential stdout messages.For instance, run a notebook with the following cell:
Then save & reload. The new output will have 56789 on one line, instead of on 5 lines like the original output.
PR #1480 now contains a fix, which is replacing
item.splitlines()
with(item+'\n').splitlines()
, which is the true inverse of'\n'.join(lines)
.The text was updated successfully, but these errors were encountered: