Thanks I thought that was also true for globals() but I now see that it is
not.
"Steven Bethard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Joe wrote:
>> Thanks, I knew about that but my question is why is it not working
>> consistently?
>
> At the module level, locals() is g
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
--
http://mail.python.org/mailman/listinfo/python-list
Steve,
Thanks, I knew about that but my question is why is it not working
consistently?
Joe
"Steven Bethard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Joe wrote:
>> Isn't this a bug?
>>
>> Here's the test program:
>>
>> import code
>>
>> def test_func():
>> lv = 1
>>
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 represen
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())
prin
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" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> code.interact() has a namespace argument ('local'), s
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 advanta
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.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
Steve Holden <[EMAIL PROTECTED]> 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, usi
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()
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
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" <[EMAIL PROTECTE
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):
>>
>> i
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
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'
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
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
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 inte
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 somethin
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
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 f
21 matches
Mail list logo
