New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Execution refactor #163
Execution refactor #163
Conversation
For cells whose last entry was itself multiline, we were executing the raw input and not the ipython translated input, so multline cells with ipython syntax were broken in this case. Also fixed history management: we now correctly store raw/translated information in the respective histories.
This will put in a single location all history-related operations, and allow us to simplify the main classes further. Readline dependencies remain (for history saving/loading), this is only a first refactoring step.
This is necessary to be able to use inputsplitter systematically across all frontends, including plain terminal one.
Fixed a number of small but tricky bugs related to prompt numbering, now in all cases I can see both terminal and gui client are fully consistent regarding prompts.
History management was moved to the history manager.
Now logging is done only by the shell in run_cell, and most uses of runlines have been replaced by the far cleaner run_cell.
I will get on this review ASAP. Thanks for doing this work! |
For future reference, I'm pasting here comments made by Min when he reviewed it over email: Min R-K's review:I saw that you removed the coding marker at the top of a couple of files. Are we not using those anymore? You left them in some files that you edited, but removed from a couple. Should I just ignore that? HistoryManager doesn't declare attributes above init.py per coding standards, are we soft about that as well? interactiveshell.py: I imagine that if we rename them, we would alias the oldnames, at least for a while. otherwise it looks very good, great work! I have a couple little spacing/comment/docstring tweaks, but if you respond to those notes, I can do the merge. -MinRK |
My replies to Min's review:
But I'm happy to revert that or agree on a different long-term policy. My preference would be to use the marks only when actually necessary (which would be pretty much only when doing testing that explicitly does unicode tests). What do you guys think?
Thanks for the review!! |
All our objects should have their interface documented at the class level before the actual constructor.
OK, I just fixed the interface, I'll do the _ names now... |
The old names are still made available for backwards compatibility.
Done, nothing more from me for now! |
Reviewed, merged, committed, and pushed. There were a couple tiny tweaks, like a space after a comma, but that's it. |
Fantastic, many many thanks! |
history.py
interactiveshell.py
prefilter.py
|
Thanks, Brian! Notes (I'm quoting by copy/paste from you): history.py
[done, good catch]
[I think we could, but it would take a fair bit of testing, and we'd have to manually implement ourselves those functions. Nothing hard, but it's not a small fix. For now we'll just keep on living with that, I'm afraid. There's only so much I can clean up one pass :) ]
[ yes! I think overall we're in much better shape with this (even with the unicode problems, which I'll work on). The architecture is right. interactiveshell.py
[ Actually those variables are slated for complete removal. Once we fully trust this system, we'll get rid of runlines, push_line and these buffers. I added a note, but won't bother changing the code since they'll just go away later.]
[ Done, good catch] Thanks again! I just committed these small fixes in 17444f9 |
Great, all of these things look fine. Thanks especially for the notes about buffer and buffer_raw and runlines. Could we add comments to the code about these things going away eventually? |
Your wish is my command, says Fernando as he whips up his time machine to answer your request, last night :) http://github.com/ipython/ipython/commit/17444f91d7191237e71714a12761c962fd9a6c1d#L1R375 But I'll add a 'pending removal' note to runlines and push_lines just now, to make sure all these entry points are clearly labeled as condemned buildings, pending demolition. |
Done in 8b47b8a. |
This looks great, thanks! |
warn instead of crashing if wrong number of args
OK, this big puppy is ready for review so we can merge it!
It's a ton of work in some of the ugliest parts of the code, but so far it looks good. I tested the merge into trunk and all tests pass, and in all usage I haven't found any regressions.
A few highlights:
much more...
I think it's good progress on one of our worst parts.