exec and thread.start_new

N

Nick Coghlan

<Sorry for the disconnected reply - I've been having news server issues, and
just switched to the mailing list instead>

Andr? Roberge said:
I don't understand why I need to use the global statement within the
definition of c() in order for it to know what a() is. If I define
exec_code() within test.py and use it there, I do not get any error,
with or without the use of a global statement.

I get the same behaviour (Windows XP, Python 2.4c1)

It seems exec is having trouble retrieving a sane locals dictionary in the
context provided by thread.start_new().

The global statement forces it to use the globals dictionary, which works correctly.

Similarly, using "exec co in dict()" (instead of "exec co") works fine (the
newly created dict is used instead of the broken one exec is currently finding).

It looks like a real bug to me (in thread.start_new_thread()), but a low
priority one, as:

1. In general, the higher-level threading module is recommended over the thread
module.
2. The 'in dict()' workaround is simple and effective

Cheers,
Nick.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

exec and locals 13
exec and global puzzle 1
use of exec() 12
get return or locals from "exec" str in "environment" 9
Python 3.X: nonlocal support in eval/exec? 2
is it a bug in exec? 3
exec with custom dict 0
Exec woes 0

Members online

No members online now.

Forum statistics

Threads
474,213
Messages
2,571,105
Members
47,698
Latest member
TerraT521

Latest Threads

Top