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