Please, this is an alpha. There are still things to polish even after a long week of hacking all together in berkley. Try not Tweet and CO. that it has been released, warn people that this is an alpha. But we gladly accept feedback (and fixes) on bugs and docs. Yes it will be on PiPy soon, but only when ready.
Telling to everyone to read the release when it is not done will make more harm than good as people continue to visit dev-doc afterward, and the current version is/will be inaccurate because of last minutes changes.
Will do, but usually the link contains `dev` prefix, the root of the doc says `1.0.0a`. We never link directly from main web site to dev doc; You have to manually enter the dev docs. It is still a lot of protection. We'll try to add a prefix on every pages.
I apologize, I'm new to HN, and not familiar with customs, good practice, and such. Perhaps I should have included ´[dev-doc]´ or ´[alpha]´ in the title.
Very cool, I'm looking forward to checking this out. Support for injecting HTML, javascript, etc. into the notebook and even loading custom css & javascript sounds great. I suspect we'll start seeing some really slick looking notebooks with pretty themes.
Woah, support for inject HTML, etc. sounds very interesting, and seems like a big deal.
On another point: I'm increasingly intrigued by the idea of having something like IPython (or perhaps, IPython itself) be used as your command-line shell. Right now it's possible, but in a bit of a long-winded way. I think this is a matter worth looking a little more into.
Those very basic operations work, but it's not feasible yet to use it exclusively as a shell and be able to do anything moderately complex without getting fancy with subprocesses and so on. Though, it's been a while since I used it (2 years) -- have things changed significantly in this time that now make it a good candidate to use as a command-line terminal?
However, still I wonder if that's enough. I mean, I can imagine that could get annoying really fast considering ! is a little tough to get to on the keyboard. Maybe a modal switch (a la vim, a mode for full blown shell, a mode with IPython being normal IPython) is a good option.
I really hope something like this eventually works out. Command-line shells seem too much like relics of the past, they can stand to be improved with some of the new UI sensibilities. IPython is one thing I can think of that is poised to fit and interact well with shells.
I upvoted you, but I am ashamed to say that I don't really understand how to use IPython notebooks. Can you recommend a good resource for learning how to use them?
So much of my exploratory work with IPython is to explore the Django models I use in my apps, and I am having trouble seeing what a notebook adds for me.
Watch a good tech talk at x2 speed. I would say most technical talks end up on Youtube and/or Vimeo (or Blip.tv). I remember there was a good one from Pycon..
Good point! I will look more closely at the Notebook site's library of samples. So far it seems like the main reason is to have documented analysis or good plots / calculations for data.
Usually I am looking less at analyzing reams of data, though, and more at the relations between objects. ("What kind of object is User.things? It's a query set, but do we ever have more than one? Do we have any users with no Thing associated?") While notebooks can surely express that, I rarely feel like I need to re-create the asking of the question. Perhaps it is that I have not yet graduated far enough in my explorations of data that a Notebook is the best tool.
I'm going to look more closely at them this week, though. Thank you for the encouragement to do so.
I use the ipython notebook sometimes, but I almost always use something similar. (In my case, I often use emacs org-mode files to make basic literate program-style documents.)
I keep these things in a dated "Notebook" file, like "Notebook/2013-07", just to hold all my one-offs.
Why do I keep them? Well, often it takes a while for me to set up the particular environment I need. If there's a problem with the calculation for X, I need to load the right data, set up the context for X, run through the individual bits until I see what the issue is.
I save the ipython notebook where I go through all that, and then if I need to go back to the calculation, for example to demonstrate to someone else my example that something has gone wrong, then I can just load up the notebook. If something is supposed to have been fixed, I can load up the notebook and repeat the calculation and see if it works now.
Unlike emacs org-mode, I can easily save the graphs as part of this. ("Look, if I plot the distribution, there's this big extra lump over there. Where's that coming from?")
If I go back to a file, it typically takes me a bit of thought to remember exactly what I was doing there. Once I figure it out again, I add sentence or two of markdown.
As a heavy numerical python user I've tried and it's cool. But as a heavy vim user I miss the code editing flexibility. My current favorite way to use ipython is through vim's Screenshell plugin.
Ok so at your behest I set up a notebook on one of my remote servers and you are right, it's pretty neat. Seems situational though. ipython proper seems a better choice for most stuff no?
But they have not fixed the embed bug that prevents you from embedding IPython within another IPython session. I find the embedded IPython so useful during debugging. I really wish it could work from within an IPython session.
For reference, the underlying cause is that IPython is written assuming that there will only be one instance of it in a process. Fixing that assumption is on our radar, but to be honest, it's quite low down the list of priorities.
I'm not familiar with embedding ipython, so maybe I"m way off the mark, but I use ipdb for the use case you're referring to. Works within ipython and all
Sounds kind of interesting, but when I go to check it out I find out that IPython 1.0 has not been released yet. Couldn't you have waited to make this post untill it was actually available? You're missing out on installs this way.
This is the documentation for the development version of IPython. I don't think they care that they're "missing out on installs" by releasing documentation about what's changed in version 1.0
However, if you'd like to try out IPython 1.0, it's an open source project. You can checkout the latest code at https://github.com/ipython/ipython
They got a grant from the Sloan Foundation several months ago to fund IPython development. It was originally going to be the 0.14 release but after the grant they updated the release roadmap, so now it's 1.0. It will replace 0.13 in pypi, I believe.
Yep, it should only become the default version you get from PyPI when it's a final release. I think PyPI/pip can handle pre-release versions without making them the default - in that case, we might put betas up.
Telling to everyone to read the release when it is not done will make more harm than good as people continue to visit dev-doc afterward, and the current version is/will be inaccurate because of last minutes changes.
Thanks a lot for your enthousiasme.