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