[IPython-dev] notebook questions

[MinRK]

On Tue, Sep 20, 2011 at 14:56, Gael Varoquaux <gael.varoquaux at normalesup.org
> wrote:

> On Tue, Sep 20, 2011 at 11:41:44AM -0700, Fernando Perez wrote:
> > On Fri, Sep 16, 2011 at 8:44 PM, Gael Varoquaux
> > <gael.varoquaux at normalesup.org> wrote:
>
> > > It seems to me wrong to go with any other markup language, given that
> the
> > > standard in the Python world in reST. It is hard enough to agree on
> > > standards, let us rejoice that there is one.
>
> > I would have hoped for less of a cheap shot coming from you.
>
> I am a bit saddened that you call this a cheap shot. I am giving a user's
> point of view that differs from your developper's point of view, but is
> definitely a point of view many people will have.
>

> > We've explained (I said it many times at Euroscipy, with lots of
> > detail)  that there are *technical* reasons why we weren't able to put
> > reST/shpinx integration into the notebook from day one, despite all of
> > us desperately wanting it.  We've heard of sphinx before, believe it
> > or not.
>
> When I was working at Enthought, in such a situation, Eric Jones would
> tell me that I am letting a technical difficulty force a user interface
> decision (he had a good sentence for that, but I can't remember it). Of
> course, it's a tradeoff: you can put the cost on the developer, or on the
> user. Depending on your target audience and the size of your development
> team, you choose the right compromise in the tradeoff space.
>
> I still expect that you will get this question many times, just like when
> I work with people that I new to Python, they keep asking me why Python
> cannot reload modules reliably. This is not the end of the world, but I
> do think that it helps to think about usability when make core choices,
> and of course balance them with the other parts of the equation. I cannot
> make choices for you.
>

Yes, many Python people will want rST instead of markdown, and they will get
it - but not like the markdown cell is done right now, with nice, responsive
single-cell rendering in the browser.  We have actually made this choice
with user experience in mind. The design of the language makes rST a very
bad choice for light interactive text cells, and when we implement rST
support, it should be for full-document formatting, where rST's advantages
can shine.

For instance, if you have a header in a text cell, would you expect that
your formatting, links, etc. be consistent throughout the document, or
independent on a per-cell basis?  It makes sense from an rST perspective
that you would want your header levels to be respected across cells.
 However, since rST simply interprets the first header-style it sees as h1,
the second as h2, etc. this means that the only reasonable option is to
rerender all cells together every single time - cells *cannot* be rendered
independently. That, combined with rST performance, means that the
interactive user experience we want is simply not achievable.  It is simply
the wrong tool for the job, from a user-experience perspective.  When we do
use rST, it will format the cells all together, in order to preserve the
scope behavior that rST writers expect.  Choosing rST will mean forfeiting
some quality of the interactive experience for the more powerful tool.  We
*will* support it, but in an appropriate manner that actually benefits from
rST's advantages over md.

-MinRK


>
> Cheers,
>
> Gael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110920/17a768de/attachment.html>