[IPython-dev] custom web notebook cells

Nicholas Bollweg nick.bollweg at gmail.com
Tue Dec 18 07:41:46 EST 2012


Hmm... I think with code generators, i have an inkling that a notation
should be used that itself is not in the target language to tell the
generator how to generate it... cog uses comments, so I kinda went there...
Decorators are a nice pun in python, as they aren't exactly "normal"... And
don't let you know when you are Done (but whitespace does), though I am not
sure what to use in JS... ideally, I'd rather that the resulting code
*didn't* have a hard dependency on the blockly generator extension (in
whatever language), but obviously we need some "metadata" (not
cell.metadata) in the code to remain robust to users doing interesting
things.

a pure JS solution is desirable, but right now I am bound by the
jsonhandler API, which means I need to emit a type that I control.... This
is why I've gone down the 2-cell path initially... also, until I get much
smarter (or see a really good example) there is stuff i don't know I CAN do
on the frontend (I.e. Get the current local names and types in scope...)
that I can do trivially on the backend. I can't even think of the
ASTQuery(tm) I would need to ask things about the current state of the code
to get what I need.

should have some refactored code up soon! The variables are tricky!

+1 on CM3... They are doing great work over there.
 On Dec 18, 2012 2:34 AM, "Matthias BUSSONNIER" <
bussonniermatthias at gmail.com> wrote:

> Le 18 déc. 2012 à 01:58, Nicholas Bollweg a écrit :
>
>
>
> >  I was already planning to do something hash-based to make sure you
> don't inadvertently destroy stuff.
> >
> >     # blockly foo
> >     def foo(bar):
> >         baz = None
> >         return baz
> >     # endblockly foo
>
>
> It's fine to use # if the notebook is bind to python,
> but don't forget that it might not always be the only case, so we probably
> won't hardcode something like that in the javascript.
>
> Also we have to achieve to bring code mirror 3.0 into the notebook.
> I don't know how much different the API is, but we already broke some User
> habits when upgrading from 2.1 to 2.3 I think.
> --
> Matthias
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20121218/f9435826/attachment.html>


More information about the IPython-dev mailing list