Re: a9709ee: second draft of eval command

Hi, I use following code snippet for exec/eval: def exec_then_eval(code, ns): block = ast.parse(code, mode='exec') if len(block.body) > 0 and isinstance(block.body[-1], ast.Expr): last = ast.Expression(block.body.pop().value) exec(compile(block, '', mode='exec'), ns)

Re: a9709ee: second draft of eval command

On Thu, Mar 29, 2018 at 11:47 AM, Terry Brown wrote: To me the entire point of the vs-eval commands was to give > the smoothest possible Python evaluation / execution in Leo - without > any additional motivations. > ​..​ > > So I don't want to limit options with the eval-* commands because of >

Re: a9709ee: second draft of eval command

On Thu, Mar 29, 2018 at 11:23 AM, Milan Melena wrote: > Hi, > > I use following code snippet for code exec/eval: > > ​​ > def exec_then_eval(code, ns): > block = ast.parse(code, mode='exec') > if len(block.body) > 0 and isinstance(block.body[-1], ast.Expr): >

Re: a9709ee: second draft of eval command

On Thu, 29 Mar 2018 10:56:32 -0500 "Edward K. Ream" wrote: > To repeat, I don't plan to going back to the old code. It is not sound > because it can't handle "else" or any other compound statement. See > the post script. The old code relied on the user to select a valid

Re: a9709ee: second draft of eval command

On Thu, 29 Mar 2018 10:36:48 -0500 "Edward K. Ream" wrote: > > > After the exec, the local dictionary contains all results. These > > > become the self.answers array. > > > > They don't seem to be in c.vs - how are the accessed now? > > ​The only "connection" is in the

Re: a9709ee: second draft of eval command

Hi, I use following code snippet for code exec/eval: def exec_then_eval(code, ns): block = ast.parse(code, mode='exec') if len(block.body) > 0 and isinstance(block.body[-1], ast.Expr): last = ast.Expression(block.body.pop().value) exec(compile(block, '', mode='exec'), ns)

Re: a9709ee: second draft of eval command

On Thursday, March 29, 2018 at 10:56:34 AM UTC-5, Edward K. Ream wrote: >From two previous posts: > This project isn't about code cleanup, it's a prototype for full jupyter support. > Some invention is required, perhaps involving eval("2+2"), but I don't have ideas at present. > It will be

Re: a9709ee: second draft of eval command

On Thu, Mar 29, 2018 at 10:36 AM, Edward K. Ream wrote: These problems​​ > ​ ​ > must be fixed with the new scheme. > ​Rev 5282399 ​ ​fixes a crasher in get_selected_lines, but that does not fix the evaluation of expressions. Indeed, exec(2+2) adds nothing to the

Re: a9709ee: second draft of eval command

On Thu, Mar 29, 2018 at 8:12 AM, Edward K. Ream wrote: Rev c27c613 correctly assigns a value to the last_result ivar, so that >> eval-replace works as expected. >> > ​And rev d48a636 updates proc_cmds in mod_http.py to use c.evalController.eval_text instead of

Re: a9709ee: second draft of eval command

On Thu, 29 Mar 2018 02:08:15 -0700 (PDT) "Edward K. Ream" wrote: > I spent quite a few happy hours yesterday and this morning completely > revising the EvalController code. Which probably makes it hard to hear a bunch of whiny criticism, but all the functionality of these

Re: a9709ee: second draft of eval command

On Thursday, March 29, 2018 at 4:08:15 AM UTC-5, Edward K. Ream wrote: > > > The evaluation of python expressions and statements has collapsed as > follows: > Rev c27c613 correctly assigns a value to the last_result ivar, so that eval-replace works as expected. Edward -- You received this

a9709ee: second draft of eval command

I spent quite a few happy hours yesterday and this morning completely revising the EvalController code. The evaluation of python expressions and statements has collapsed as follows: *do_exec*: Only exec is used, never eval. The code works for both python 2 and 3. After the exec, the local