<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Le 25 févr. 2013 à 18:14, MinRK a écrit :</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Mon, Feb 25, 2013 at 9:06 AM, Matthias BUSSONNIER <span dir="ltr"><<a href="mailto:bussonniermatthias@gmail.com" target="_blank">bussonniermatthias@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>From a first quick read, I would be -1 on whitelisting types.</div><div>The strength of nbformat is that it embeds **all** the data type that are available afterward with nbconvert for example.</div>
<div>A frontend does not need to know how to show a format to store it in the file.</div></div></blockquote><div><br></div><div>You have misunderstood. The principal use case for this is in-process IPython,</div><div>where output is not saved, and there is zero uncertainty about unsupported display formats.</div>
<div>The notebook is not relevant here, and this makes no changes at all to the behavior in the notebook.</div></div></blockquote><div><br></div><div>Ah, ok, I missed that.</div><div><br></div><div>Too many mails to read…</div><div>-- </div><div>Matthias</div></div><br></body></html>