I have a list of features I want to start adding to bpython. However, I've found the biggest obstacle to contributing to be the monster-ish nature of the Repl class. I was thinking that it might be a good idea to try to break it up in to the constituent components of a REPL: input, output, history, loop (others?). With relatively loose bindings between the classes and their magic kept less exposed, I think the repl module will be easier to extend, but that could just be my lack of familiarity with the codebase and/or incompetence showing through. So, before diving in and just doing this, I wanted to hear your thoughts on whether it is something you think to be a productive direction to take, and whether anyone wants to help with it.
As for implementing multi-line editing, I don't want to just plop it down, I want it to feel natural. These are my thoughts for the kinds of things that should be done to make using bpython as natural as the Python interpreter while implementing multi-line history editing, but I want to know if I'm heading in a direction you don't like or missing something, etc. I've setup a fork of bpython to start working on this stuff at http://bitbucket.org/james.sams/bpython if you want to follow the work. My WishList: - 3 input types (configurable, maybe not switchable during a session) * singe line ala Python Interp (e.g. now) * Multiline w/ mixed input/output (e.g. ipython) * Multiline w/ separate editor (e.g. DreamPie) - Proposed Keyboard behavior with multi-line editing: * PEP8 friendliness: aka blank lines don't cause a send to interp (^enter?) * up/C-p within mulitline goes through those lines * up/C-p on first line of multiline goes up in history * M-up/M-p cycles up through history blocks - how do you define alt keys in keys.py? * down/C-n within multiline goes through those lines * down/C-n on last line of multiline goes down in history * M-down/M-p cycles down through history blocks ? Should the line position save state when switching from and back to a block, or always start at top/bottom? I can see confusion in both cases, jumping to top/bottom of block w/ keyboard would be good. - Solution: when switching block with by moving up, start at bottom of block, when moving down, start at top of block? - Pastebin changes (which of these are available depend on input type): * paste only current editor as Python code, * editor with run output as Python Interp session, * run output only (what syntax style to apply?), * and current behavior - Current editor to clipboard - Keyboard switching b/w input and output; consistent scrolling in both, selection? - allow setting of output printer, e.g. to pprint.pprint in config -- You received this message because you are subscribed to the Google Groups "bpython" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/bpython?hl=en.
