[IPython-dev] questions about the notebook interface
antont at an.org
Tue Jun 28 11:36:40 EDT 2005
Fernando Perez wrote:
(btw just noticed that the message i'm replying to did not go to the
list, at least i can't see it in the web archives - i suppose that was
hi again and thank you all of you for the comments - quite a lot to
digest, and i actually had some other things to do today too .. am
throwing some more stuff in still based on the notes from the morning,
hopefully they open up some perspectives. oh and the answers were quite
helpful, many things are clearer now.
>> as e.g. rst is nice for writing documents in itself, and can also be
>> used to write text, make tables, images etc. in Python files (the
>> original purpose), i'd be interested in hearing the main
> There was also the possibility of leaving the top-level syntax as
> Python, but embedding the markup in specially-tagged comments or
> triple-quoted strings. Eventually, after discussing this approach at
> length with John Hunter (matplotlib), I was convinced that using the
> Python language itself would be the cleanest approach. If we start
> embedding markup in strings, we'll need to write our own parsing,
> processing, etc. It's just cleaner to simply expose that as true
> python objects and be done
hm, except if we just used rst, 'cause docutils can already parse that
in .py files - right?
> with it. Python is a very powerful programming language, why not use
> it to represent the structure of the document?
(dismissing now the point that the code must be executed to have the doc
;) ((btw i guess it's well possible to cache objects, like the results
of complex calculations))
a couple of things about that:
> abstract representation of the structure of a document, in terms of
> calls to things like
> markup.title('my doc title')
> markup.heading('first heading')
> markup.text('some regular text...')
will we have an own abstraction, notebook.title, notebook.heading etc.,
like docutils/rst has, and then different writers for pdf, html etc.
(again like docutils has)? or is it better to use some of the existing
'document objects models', like the one that rst, latex, html or
something uses? (like your example with rest.title and latex.title would
indicate). and if using rest and/or latex directly like that, are they
mutually exclusive, i.e. does it mean that one notebook can contain only
one kind of markup? 'cause doing rest.title() and latex.section() in the
same doc would be quite strange..
hm perhaps your following text already answered that, but i'm not yet
> If the user simply sticks to plain text everywhere, the documents can
> render more or less across backends. But users are free to pass
> things like
> markup.text('and now let us define $f(x)=x+1$ ...')
> which will obviously not render as math in anything but a latex-based
> Something like this gives a generic object abstraction, along with a
> mechanism to access the low-level capabilities of a specific backend.
>> 3. markup
> I don't see how in this approach one can have top-level code woven
> inside the page template, but perhaps it's possible. I'd encourage
> you to play with it a bit, and let me know how it feels for our target
ok i might explore it - but here is something perhaps interesting in a
different direction, Python notebooks the (meta)class way .. perhaps
this is also a comment to how writing Python can be more powerful than
writing xml..? :
from notebook import Section, Image, Reference #like there was the own
from notebook.constants import *
class introduction(Section): #a singleton class, i.e. a section called
+ "This is the first paragraph in the introduction section."
+ "Although this may seem quite peculiar, it's still pure
Python!(?)" #2nd paragraph
+ "This way to use metaclasses for compact descriptions of content
items as singletons, featuring 'operator overloading' etc., is taken
directly from mr. de Ridder's Blendit, see" +
of 3rd paragraph so far
background = Section() #the same without (meta)class trickery
background += "Now this is just another section, created in more typical
background += Image("smiley")
class forfun(Image): #and back to classes (blendit uses metaclasses for
src = "drawing.svg"
align = CENTER #a notebook.constant
size = 0.50
introduction += forfun
that's of course totally non-tested, not too much thought over, and not
commented by anyone before..
> Yes, the markup project should be mostly independent of ipython. Much
> like matplotlib, which can be used non-interactively on its own, or
> interactively with ipython. This means that initially, Toni's project
> can live on its own, while Tsanko will need to work much more closely
> with me on
i'll start on this machine here, and commit things to the repository
once it's set up.
> I've thought that XEmacs could be the first environment to target for
> interactive use, since it already almost has everything we need in its
> python-mode/ipython combination. In the meantime, Tsanko can work on
> the more ambitious GUI-oriented project he applied for.
fine with me, as emacs is what i always use for programming otherwise too.
.. looking forward to hearing the GUI ideas too
More information about the IPython-dev