pyzo
Allow to see code that was run for each input
Originally reported by: BrenBarn (Bitbucket: BrenBarn, GitHub: BrenBarn)
Currently when code from the editor is run in the shell, IEP only shows a generic message like "executing lines XXX-YYY". It would be good to have the actual code that was run accessible. When doing interactive work, I sometimes want to go back to an earlier version of some code. In particular, I sometimes want to go back to a certain output and see what code generated it.
I think the simplest thing would be to have IEP show, in the shell window, the actual code that was run, right before the output that it created. Ideally this could be folded and unfolded a la issue #284 to allow hiding of long code snippets in the output. This is how DreamPie works and it provides a very nice workflow.
- Bitbucket: https://bitbucket.org/iep-project/iep/issue/303
Original comment by BrenBarn (Bitbucket: BrenBarn, GitHub: BrenBarn):
I've had this idea some time ago to implement a notebook-like feature in IEP. The idea was to make it rather lightweight, and it would simply be a .py file where the code is cut at the cells ## and any output is shown below each cell. It should only take one push of the buttom to transform back to 'classic' code editing. This is presumable quite a bit of work to implement, and I suspected it would not add so much since there is the IPython notebook that is so much more developed in that respect. What do you think?
Sounds very cool! It definitely sounds more like what I'm looking for. I can certainly understand if it's not a high development priority given the overlap with IPNB, but at the least it would be something to keep in mind for the future. I think there is considerable scope for Python tools that provide interactive workflows similar to IPNB, but do so in a "real" GUI app that provides considerably more flexibility than a browser.
For the record, IEP also uses such an architecture; each shell that you start runs in its own process.
Yes, but in IEP that is all wrapped into the same program. What I meant is that with IPNB the server actually has to be started separately from the client. This means that, for instance, the various options like pylab and matplotlib backends cannot be set from within the notebook UI itself, but must be specified externally when you run the server. It's nice to have something like IEP where the configuration of the shell is in the same UI as the running shell itself.
Original comment by Almar Klein (Bitbucket: almarklein, GitHub: almarklein):
Interesting... I completely agree that IPython is not suitable for all workflows, especially when working on larger pieces of code --- or I would not work on IEP :)
My initial line of thought that you could just use both tools, picking either one based on what you want to do. But the real world is probably not so black and white, and you may want to transition more smoothly from one way of working to another. Plus you need to know how to use two tools instead of one. I actually never use IPython notebook, because I get around IEP very well, although part of this may be just habbits.
I've had this idea some time ago to implement a notebook-like feature in IEP. The idea was to make it rather lightweight, and it would simply be a .py file where the code is cut at the cells ## and any output is shown below each cell. It should only take one push of the buttom to transform back to 'classic' code editing. This is presumable quite a bit of work to implement, and I suspected it would not add so much since there is the IPython notebook that is so much more developed in that respect. What do you think?
Also, the client-server architecture of IPython, while indispensable for some applications, makes it somewhat more unwieldly than a single-program IDE.
For the record, IEP also uses such an architecture; each shell that you start runs in its own process.
Original comment by BrenBarn (Bitbucket: BrenBarn, GitHub: BrenBarn):
I suppose some sort of popup thing could work. Again, in DreamPie the code can be folded, so one possibility would be to have it folded down but expandable with a click. Or maybe there could be a customizable cutoff for code size above which the code wouldn't be shown.
And yeah, I've seen IPython notebook and it's pretty cool! You're right that some of what I want is provided there, but I think you're also right that I want it all :-)
One problem I have with the IPython notebook is that it runs in a web browser. This limits the flexibility of the UI --- an interface like IEP's, with separate panels for different tools, is very appealing, and especially so because those tools are pluggable, so that it can be expanded with new ideas. In general I've found that complex, multi-panel UIs tend to get annoying in a browser because in trying to do things within the page UI, the user begins to bump up awkwardly against the browser UI. The kind of IDE I like would indeed offer a lot of the interactive flexibility of the notebook, but in a "real" UI that allows it to be combined with various features like those IEP provides. Also, the client-server architecture of IPython, while indispensable for some applications, makes it somewhat more unwieldly than a single-program IDE.
Also, when you write an IPython notebook, what you've written is an IPython notebook. I think there's value in a tool like IEP for interactively trying out code on the way towards writing an actual program --- that is, the end result is something you could distribute as Python code to be run and used by someone who just uses Python. In contrast, as I understand it, the only end result you can get from the notebook is the complete code-output package. So basically what I'm describing is a setup where the development process may be interactive but the end result is standalone code rather than a "document" including input and output.
Original comment by Almar Klein (Bitbucket: almarklein, GitHub: almarklein):
BTW: it sounds a bit like you need the IPython notebook :P But seriously, the IPython notebook allows one very interactive way of working, whereas IEP is slighly more 'classic' development. It sounds like you want both. I am a wee bit sceptical to whether this would work, especially for showing all executed code by default. But I am very open to good arguments, of course ;)
Original comment by Almar Klein (Bitbucket: almarklein, GitHub: almarklein):
What if the executed code is big, like a 1000-line file? I lean more towards a popup-kind of solution, what do you think?