[IPython-user] [IPython-dev] Development plans update

wang frank fw3@hotmail.co...
Sat Feb 2 21:49:55 CST 2008

How about a way to copy a group of data into ipython similar like copy the code now? It is important since sometimes, we want to copy a group of data from other application and assign it to a python variable.
Frank> Date: Sat, 2 Feb 2008 10:33:55 +0200> From: vivainio@gmail.com> To: ellisonbg.net@gmail.com> CC: ipython-user@scipy.org; fperez.net@gmail.com; ipython-dev@scipy.org> Subject: Re: [IPython-user] [IPython-dev] Development plans update> > On Feb 2, 2008 1:04 AM, Brian Granger <ellisonbg.net@gmail.com> wrote:> > > 2. Prompt display. IPython prompts can include info from the users namespace.> > I think the prompt calculation should be done in the back-end. Isn't> it trivial for the frontend to ask for the prompt string from the back> end (even if it doesn't happen by merely writing out the characters)?> > > 3. Traceback printing. Tracebacks are formatted (ACSII coloring,> > etc) by ipython at the moment the exception is raised, when the full> > state of the interpreter is available to look at.> > Why can't the back end just render the exception string, and let the> display be handled by front end? We can change the color escape> sequences to something more "universal", if need be (<red>foo</red>,> <highlight>NOTE</highlight>, whatever).> > > whatever way is best. While this doesn't look too bad there is a lot> > of subtlety going on underneath the hood. For example, the complete> > method could actually trigger a network call to ipython core/engine> > running on a remote system. At the time the complete call gets made,> > the engine could be executing some blocking C code the user had> > started in a previous line. In this case, the tab completion can't> > happen until that C code finishes (threads won't help). So, then, in> > a case like that, the complete method will need to raise an exception> > to reflect the fact that TAB completion can't happen right now.> > If we have the part that communicates with the front end in a separate> thread, this won't be a problem. Completion can ALWAYS happen. This is> probably easy stuff, apart from ctrl+c handling.> > > Prompts. If a frontend wants a prompt to include information from an> > object in the users namespace, the frontend will have to get the> > object (over the network possibly) each time it wants to update the> > information:> >> > a = interpreter.pull('a')> >> > This gets the object named 'a' from the users namespace. Again, this> > can potentially be a non-local (network) call, that is not completed> > immediately.> > If we ask for the whole prompt from the back end, we know when it will> be fully ready. Here, the complications are in the front end.> > > Displaying things. The core of ipython1 will not be able to make any> > decisions about how things (stdout, tracebacks, etc) are formatted.> > This is because a single instance of the core could be simultaneously> > connected to frontends that need things formatted in completely> > different ways. You could have a Javascript frontend, a terminal> > based frontend and a Qt app all talking to the same instance of the> > core. Because of this, the core will need to return output in a> > "unformatted format." (xml, python dict, etc) that can transformed by> > the frontends into whatever form they need.> > Yeah, this is what I referred to earlier. Changing what the back end> blurts out to xml should be pretty easy, and a trivial front end> implementation (a readline one) can just do string replace to convert> it to the current ansi codes.> > > to varous methods of the interpreter. This is what I mean that the> > "core" won't know anything about display hooks. They will still> > exist, but look very different.> > I think the display hooks should still be in core, but return strings> instead of direct printing.> > > Does this help give a better idea about why the APIs will look so different?> > Yes. Meetings these expectations seems like a pretty fun project, though :-)> > -- > Ville M. Vainio - vivainio.googlepages.com> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'> _______________________________________________> IPython-user mailing list> IPython-user@scipy.org> http://lists.ipython.scipy.org/mailman/listinfo/ipython-user
「初音ミク」の妹分「鏡音リン」をLive Search で画像検索!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ipython.scipy.org/pipermail/ipython-user/attachments/20080203/346de888/attachment.html 

More information about the IPython-user mailing list