By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,573 Members | 907 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,573 IT Pros & Developers. It's quick & easy.

python -i (interactive environment)

P: n/a
Joe
When you run "python -i scriptname.py" after the script completes you left
at the interactive command prompt.

Is there a way to have this occur from a running program?

In other words can I just run scriptname.py (NOT python -i scriptname.py)
and inside of scriptname.py I decide that I want to fall back to the
interactive prompt?

I've searched and so far the only thing I've come up with is to use pdb, but
that is not exactly the same as the interactive prompt.

Is there any way to do it that I have missed?

Thanks.
Jul 18 '05 #1
Share this Question
Share on Google+
20 Replies


P: n/a
Very simple is you're on UNIX ...

You juste have to put at the beginnin of your file :

#!/usr/bin/python -i

And it juste does what you want :)

Pierre

Joe a écrit :
When you run "python -i scriptname.py" after the script completes you left
at the interactive command prompt.

Is there a way to have this occur from a running program?

In other words can I just run scriptname.py (NOT python -i scriptname.py)
and inside of scriptname.py I decide that I want to fall back to the
interactive prompt?

I've searched and so far the only thing I've come up with is to use pdb, but
that is not exactly the same as the interactive prompt.

Is there any way to do it that I have missed?

Thanks.

Jul 18 '05 #2

P: n/a
Joe
Hi Pierre,

Thanks for the reply, but I am not on Unix and it even if I was that
solution it does not achieve the desired results.

I want the script to decide whether to fall back to the interactive prompt.
You solution makes it ALWAYS fall back to the interactive prompt.

I want to do something like:

try:
# execute code
except MyExceptionOccurred, except_msg:
# fall to interactive prompt.

In other words I want to have my program to determine whether the
interactive prompt to be displayed or not.

Thanks!
"Pierre Barbier de Reuille" <pi************@cirad.fr> wrote in message
news:42***********************@news.free.fr...
Very simple is you're on UNIX ...

You juste have to put at the beginnin of your file :

#!/usr/bin/python -i

And it juste does what you want :)

Pierre

Joe a écrit :
When you run "python -i scriptname.py" after the script completes you
left at the interactive command prompt.

Is there a way to have this occur from a running program?

In other words can I just run scriptname.py (NOT python -i scriptname.py)
and inside of scriptname.py I decide that I want to fall back to the
interactive prompt?

I've searched and so far the only thing I've come up with is to use pdb,
but that is not exactly the same as the interactive prompt.

Is there any way to do it that I have missed?

Thanks.

Jul 18 '05 #3

P: n/a
Joe wrote:
I want the script to decide whether to fall back to the interactive prompt.
You solution makes it ALWAYS fall back to the interactive prompt.


Actually, using sys.exit() means the program can exit even if python -i
is used.

You can use:

import code
code.interact()

which emulates the interactive prompt.
--
Michael Hoffman
Jul 18 '05 #4

P: n/a
I posted the following a while back. I think this is what you are
looking for.

This can be done fairly easily by creating a module (lets call it
interactive) with the following code in it.
-----------
import sys,os

def debug_exception(type, value, traceback):
# Restore redirected standard I/O
sys.stdin = sys.__stdin__
sys.stdout = sys.__stdout__
sys.stderr = sys.__stderr__

# Kick the interpreter into interactive mode and call the original
# exception handler.
os.environ['PYTHONINSPECT'] = '1'
sys.__excepthook__(type, value, traceback)

sys.excepthook = debug_exception
-----------

Now if you import this module and raise an unhandled exception, you will
be in interactive mode. In other words, I think the following script
does what you are asking for.

-----------
import interactive

raise RuntimeError('Interactive Mode')
-----------

This also has the advantage that if there are no unhandled exceptions in
your script, the script runs and terminates normally.

Enjoy,
Ray Buvel

Joe wrote:
Hi Pierre,

Thanks for the reply, but I am not on Unix and it even if I was that
solution it does not achieve the desired results.

I want the script to decide whether to fall back to the interactive prompt.
You solution makes it ALWAYS fall back to the interactive prompt.

I want to do something like:

try:
# execute code
except MyExceptionOccurred, except_msg:
# fall to interactive prompt.

In other words I want to have my program to determine whether the
interactive prompt to be displayed or not.

Thanks!
"Pierre Barbier de Reuille" <pi************@cirad.fr> wrote in message
news:42***********************@news.free.fr...
Very simple is you're on UNIX ...

You juste have to put at the beginnin of your file :

#!/usr/bin/python -i

And it juste does what you want :)

Pierre

Joe a écrit :
When you run "python -i scriptname.py" after the script completes you
left at the interactive command prompt.

Is there a way to have this occur from a running program?

In other words can I just run scriptname.py (NOT python -i scriptname.py)
and inside of scriptname.py I decide that I want to fall back to the
interactive prompt?

I've searched and so far the only thing I've come up with is to use pdb,
but that is not exactly the same as the interactive prompt.

Is there any way to do it that I have missed?

Thanks.


Jul 18 '05 #5

P: n/a
Joe wrote:
When you run "python -i scriptname.py" after the script completes you left
at the interactive command prompt.

Is there a way to have this occur from a running program?

In other words can I just run scriptname.py (NOT python -i scriptname.py)
and inside of scriptname.py I decide that I want to fall back to the
interactive prompt?

I've searched and so far the only thing I've come up with is to use pdb, but
that is not exactly the same as the interactive prompt.

Is there any way to do it that I have missed?

Thanks.


Yes you can set the PYTHONINSPECT environment variable to something
other than an empty string from within your program.

MikeG
Jul 18 '05 #6

P: n/a
Joe
Thanks Michael, that's what I was looking for.

Are there any differences between that and the actual interactve prompt that
I should be aware of?

Would you consider that a better method than using (thanks to those who
suggested this other option):

import os
os.environ['PYTHONINSPECT'] = '1'
"Michael Hoffman" <ca*******@mh391.invalid> wrote in message
news:d0**********@gemini.csx.cam.ac.uk...
Joe wrote:
I want the script to decide whether to fall back to the interactive
prompt. You solution makes it ALWAYS fall back to the interactive prompt.


Actually, using sys.exit() means the program can exit even if python -i
is used.

You can use:

import code
code.interact()

which emulates the interactive prompt.
--
Michael Hoffman

Jul 18 '05 #7

P: n/a
Joe wrote:
Are there any differences between that and the actual interactve prompt that
I should be aware of?
I don't know, unfortunately.
Would you consider that a better method than using (thanks to those who
suggested this other option):

import os
os.environ['PYTHONINSPECT'] = '1'


Actually I would do that everyone else suggested for your use case. I thought
about trying this method but couldn't imagine that it would actually work!
--
Michael Hoffman
Jul 18 '05 #8

P: n/a
Joe
Funny you said that, because I didn't even bother trying it because I didn't
think it would work either. I figured that python did something internally
when it saw the -i switch. Looks like it just checks for it when it's done
with your code.

One difference between the two methods that I see is that when you set
PYTHONINSPECT you don't really have to do anything else and unless
sys.exit() or raise SystemExit is used you will get the interactive prompt.

Using code.interact you would need to wrap everything in a try/except block
and call code.interact from there, or you could invoke it whenever you
wanted too. This has the advantage that you can even trap SystemExit if you
want too.

Thanks again to everyone!
"Michael Hoffman" <ca*******@mh391.invalid> wrote in message
news:d0**********@gemini.csx.cam.ac.uk...
Joe wrote:

Actually I would do that everyone else suggested for your use case. I
thought
about trying this method but couldn't imagine that it would actually work!
--
Michael Hoffman

Jul 18 '05 #9

P: n/a
Michael Hoffman wrote:
Joe wrote:
Are there any differences between that and the actual interactve prompt that
I should be aware of?


I don't know, unfortunately.
Would you consider that a better method than using (thanks to those who
suggested this other option):

import os
os.environ['PYTHONINSPECT'] = '1'


Actually I would do that everyone else suggested for your use case. I thought
about trying this method but couldn't imagine that it would actually work!


Actually, using this behavior is encouraged by the developers. See this
comment in Modules/main.c:

/* Check this environment variable at the end, to give programs the
* opportunity to set it from Python.
*/

Reinhold
Jul 18 '05 #10

P: n/a
Joe
Reinhold,

Interesting.

A key difference between the two is that PYTHONINSPECT will allow you access
to the prompt at the end of your program (assuming no sys.exit or raise
SystemExit) but code.interact() allows you to jump into the program at any
point.
"Reinhold Birkenfeld" <re************************@wolke7.net> wrote in
message news:39*************@individual.net...
/* Check this environment variable at the end, to give programs the
* opportunity to set it from Python.
*/

Reinhold

Jul 18 '05 #11

P: n/a
Michael Hoffman wrote:
Joe wrote:
I want the script to decide whether to fall back to the interactive
prompt. You solution makes it ALWAYS fall back to the interactive prompt.

Actually, using sys.exit() means the program can exit even if python -i
is used.

You can use:

import code
code.interact()

which emulates the interactive prompt.


Unfortunately it does so in an entirely new namespace, thereby losing
the advantage of -i - namely, that you can investigate the program's
namespace after it's terminated.

regards
Steve

Jul 18 '05 #12

P: n/a
In article <ma************************************@python.org >,
Steve Holden <st***@holdenweb.com> wrote:
Michael Hoffman wrote:
Joe wrote:
I want the script to decide whether to fall back to the interactive
prompt. You solution makes it ALWAYS fall back to the interactive prompt.

Actually, using sys.exit() means the program can exit even if python -i
is used.

You can use:

import code
code.interact()

which emulates the interactive prompt.


Unfortunately it does so in an entirely new namespace, thereby losing
the advantage of -i - namely, that you can investigate the program's
namespace after it's terminated.


code.interact() has a namespace argument ('local'), so it really easy to
have it use the namespace you want.

Just
Jul 18 '05 #13

P: n/a
When I'm using pyunit and want to stop in a point during the test
(skipping all the framework initialization), I just start the debugger:

import pdb
pdb.set_trace()

You'll get the debugger prompt.

Jul 18 '05 #14

P: n/a
Joe
Found that out :-(

You can use the local=locals() option so at least you have access to the
local variables, which in the case of debugging, is exactly what I needed.

Since -i gives you control at the end of the program the locals are already
gone.

Seems like both approaches have their advantages depending on the situation.

"Steve Holden" <st***@holdenweb.com> wrote in message
news:ma************************************@python .org...
Unfortunately it does so in an entirely new namespace, thereby losing the
advantage of -i - namely, that you can investigate the program's namespace
after it's terminated.

Jul 18 '05 #15

P: n/a
Joe
Right, but only one namespace. Would be nice if there was a way to give it
both the global and the local namespaces. In my case though the local
namespace was sufficient.

"Just" <ju**@xs4all.nl> wrote in message
news:ju************************@news1.news.xs4all. nl...
code.interact() has a namespace argument ('local'), so it really easy to
have it use the namespace you want.

Just

Jul 18 '05 #16

P: n/a
Joe
Isn't this a bug?

Here's the test program:

import code

def test_func():
lv = 1
print '\n\nBEFORE lv: %s\n' % (lv)
code.interact(local=locals())
print '\n\nAFTER lv: %s\n' % (lv)
return

test_func()

gv = 1
print '\n\nBEFORE gv: %s\n' % (gv)
code.interact(local=locals())
print '\n\nAFTER gv: %s\n' % (gv)

Here's the output and interactive session:

BEFORE lv: 1

Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
lv = 2
print lv 2 ^Z
AFTER lv: 1

BEFORE gv: 1

Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole) gv = 2
print gv 2 ^Z

AFTER gv: 2

In the case of code.interact being called inside the function, the locals
were available to the interactive environment but changes did not stick when
you returned back the function. (started as lv=1 changed to lv=2 in
interactive session, back to lv=1 in function) Since you are still in the
function and since code.interact used the same local environment why didn't
the change stick until testfunc ended?

When code.interact was called from the outside the function (globals() ==
locals()) the changes stuck. (started as gv=1, changed to gv=2 in
interactive session, stuck as gv=2 back in main).

"Steve Holden" <st***@holdenweb.com> wrote in message
news:ma************************************@python .org... Michael Hoffman wrote:
Joe wrote:
I want the script to decide whether to fall back to the interactive
prompt. You solution makes it ALWAYS fall back to the interactive
prompt.

Actually, using sys.exit() means the program can exit even if python -i
is used.

You can use:

import code
code.interact()

which emulates the interactive prompt.


Unfortunately it does so in an entirely new namespace, thereby losing the
advantage of -i - namely, that you can investigate the program's namespace
after it's terminated.

regards
Steve

Jul 18 '05 #17

P: n/a
Joe wrote:
Isn't this a bug?

Here's the test program:

import code

def test_func():
lv = 1
print '\n\nBEFORE lv: %s\n' % (lv)
code.interact(local=locals())
print '\n\nAFTER lv: %s\n' % (lv)
return


Check the documentation for locals() [1]:

"Update and return a dictionary representing the current local symbol
table. Warning: The contents of this dictionary should not be modified;
changes may not affect the values of local variables used by the
interpreter."

So if you change things in the dictionary returned by locals() you won't
actually change the local variables.

STeVe

[1] http://docs.python.org/lib/built-in-funcs.html#l2h-45
Jul 18 '05 #18

P: n/a
Joe
Steve,

Thanks, I knew about that but my question is why is it not working
consistently?

Joe
"Steven Bethard" <st************@gmail.com> wrote in message
news:09********************@comcast.com...
Joe wrote:
Isn't this a bug?

Here's the test program:

import code

def test_func():
lv = 1
print '\n\nBEFORE lv: %s\n' % (lv)
code.interact(local=locals())
print '\n\nAFTER lv: %s\n' % (lv)
return


Check the documentation for locals() [1]:

"Update and return a dictionary representing the current local symbol
table. Warning: The contents of this dictionary should not be modified;
changes may not affect the values of local variables used by the
interpreter."

So if you change things in the dictionary returned by locals() you won't
actually change the local variables.

STeVe

[1] http://docs.python.org/lib/built-in-funcs.html#l2h-45

Jul 18 '05 #19

P: n/a
Joe wrote:
Thanks, I knew about that but my question is why is it not working
consistently?


At the module level, locals() is globals():

py> locals() is globals()
True

And the globals() dict is modifiable.

HTH,

STeVe
Jul 18 '05 #20

P: n/a
Joe
Thanks I thought that was also true for globals() but I now see that it is
not.

"Steven Bethard" <st************@gmail.com> wrote in message
news:Vd********************@comcast.com...
Joe wrote:
Thanks, I knew about that but my question is why is it not working
consistently?


At the module level, locals() is globals():

py> locals() is globals()
True

And the globals() dict is modifiable.

HTH,

STeVe

Jul 18 '05 #21

This discussion thread is closed

Replies have been disabled for this discussion.