eval or execute, is this the (most) correct way ?

[Stef Mientki]

hello,

I'm trying to make an editor with an integrated Shell.

>>So when type:

2+5

>>I want the answer on the next line:

7

>>When I type:

myvar = 55
myvar

>>I want the value of myvar:

55

So AFAIK, sometimes I've to use eval and sometimes I need exec,
so I use the following code (global / local dictionary parameters are
left out in this example):

try:
print eval ( line )
except :
exec ( line )

Is this the (most) correct / elegant way, or are there better solutions ?

I read somewhere that exec is going to disappear,
and noticed that in 2.5 (I just updated to) the doc is already disapeared,
is this no longer possible in Python 3 ?

thanks,
Stef Mientki

[Steven D'Aprano]

On Mon, 11 Aug 2008 17:26:56 +0200, Stef Mientki wrote:

I'm trying to make an editor with an integrated Shell.

....

Is this the (most) correct / elegant way, or are there better solutions
?

The best solution is not to re-invent the wheel: "import code" is the way
to emulate Python's interactive interpreter. Try running "python -m code"
at a regular shell (not the Python shell, your operating system's shell).

Doing a search of the file code.py, I don't find the string "eval" at
all. My guess is that your approach is probably not the best way.

--
Steven

[Stef Mientki]

Steven D'Aprano wrote:

On Mon, 11 Aug 2008 17:26:56 +0200, Stef Mientki wrote:

>I'm trying to make an editor with an integrated Shell.

...

>Is this the (most) correct / elegant way, or are there better solutions
?

The best solution is not to re-invent the wheel: "import code" is the way
to emulate Python's interactive interpreter.

sorry, but that confuses me even more,
I don;t have a file / module,
just a workspace and one or more lines of code in memory.

Try running "python -m code"
at a regular shell (not the Python shell, your operating system's shell).

I might have been not clear enough,
I'm trying to build an python-IDE,
so I definitely want to run code from memory.

cheers,
Stef

Doing a search of the file code.py, I don't find the string "eval" at
all. My guess is that your approach is probably not the best way.

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

So AFAIK, sometimes I've to use eval and sometimes I need exec,

so I use the following code (global / local dictionary parameters are
left out in this example):
Is this the (most) correct / elegant way, or are there better solutions ?

You should be using compile with the "single" start symbol, and then
use eval on the resulting code option.

I read somewhere that exec is going to disappear,

That's not true. exec stops being a statement, and becomes a function
(like print).

Regards,
Martin

[Stef Mientki]

Martin v. Löwis wrote:

>So AFAIK, sometimes I've to use eval and sometimes I need exec,
so I use the following code (global / local dictionary parameters are
left out in this example):
Is this the (most) correct / elegant way, or are there better solutions ?

You should be using compile with the "single" start symbol, and then
use eval on the resulting code option.

thanks Martin,
but when I read the doc (of one of the many) "compile" functions,
I see 2 problems:
- I still have to provide "kind" as exec or eval
- I can not specify the global and local namespace (which is essential
for me)

>I read somewhere that exec is going to disappear,

That's not true. exec stops being a statement, and becomes a function
(like print).

That's good to hear,
as I already didn't realize it could also be used as a statement ;-)

cheers,
Stef

Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list

[Terry Reedy]

Stef Mientki wrote:

Steven D'Aprano wrote:

>The best solution is not to re-invent the wheel: "import code" is the
way to emulate Python's interactive interpreter.

sorry, but that confuses me even more,

"The code module provides facilities to implement read-eval-print loops
in Python. Two classes and convenience functions are included which can
be used to build applications which provide an interactive interpreter
prompt." IDLE uses it to do just that. File idelib/pyshell.py imports
InteractiveInterpreter. A quarter of the file is the definition of
class ModifiedInterpreter(InteractiveInterpreter):

I don;t have a file / module,
just a workspace and one or more lines of code in memory.

The code module has many options. "InteractiveConsole.push(line)
Push a line of source text to the interpreter. "

Anyway, your first post indicated that those 'lines of code in memory'
originate from console input, which, I believe, is the default input
source for the classes. You will need to experiment to see just how
they work.

>Doing a search of the file code.py, I don't find the string "eval" at
all. My guess is that your approach is probably not the best way.

It would use 'exec' on statements, even if they happen to be expression
statements. Exec is not going away. It is a built-in function in 3.0.

Terry Jan Reedy

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

>You should be using compile with the "single" start symbol, and then

>use eval on the resulting code option.

thanks Martin,
but when I read the doc (of one of the many) "compile" functions,
I see 2 problems:
- I still have to provide "kind" as exec or eval

No, you can also use "single".

- I can not specify the global and local namespace (which is essential
for me)

You do so not in compile, but in eval.

That's good to hear,
as I already didn't realize it could also be used as a statement ;-)

It *is* a statement, and always was. A "statement" is a fragment of
code that just gets executed, and doesn't produce a value (unlike
an expression, which does produce a value). So you can't write

x = exec "1+1"

or

foo(exec)

whereas you *can* write

x = eval("1+1")

and

foo(eval)

Likewise, you cannot write in Python 2.x, but can write in 3.x

x = print("Hello")

and

foo(print)

Things like "for", "while", "return", and assignments are statements,
things like "+", "**", lambda, function calls are expressions. print
and exec are statements in 2.x, and functions (thus, expressions)
in 3.x.

Regards,
Martin