[IPython-dev] questions about the notebook interface

Toni Alatalo antont at an.org
Tue Jun 28 10:36:40 CDT 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 
in error?)

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?

right.
(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 
sure how.

> 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 
> backend.
> Something like this gives a generic object abstraction, along with a 
> mechanism to access the low-level capabilities of a specific backend.  

(...)

>> 3. markup
>> http://nevowexamples.adytum.us/sources/hellostan.py
>
> 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 
> problem.

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..? :

---begin---

from notebook import Section, Image, Reference #like there was the own 
abstraction
from notebook.constants import *

class introduction(Section): #a singleton class, i.e. a section called 
"introduction"
    + "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" + 
Reference("http://www.blender3d.org/cms/Theo_de_Ridder.459.0.html") #end 
of 3rd paragraph so far

background = Section() #the same without (meta)class trickery
background += "Now this is just another section, created in more typical 
Python fashion."
background += Image("smiley")

class forfun(Image): #and back to classes (blendit uses metaclasses for 
these somehow)
    src = "drawing.svg"
    align = CENTER #a notebook.constant
    size = 0.50

introduction += forfun

---end---

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 

ok.

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

> Fernando

~Toni




More information about the IPython-dev mailing list