N
Nick Coghlan
<Sorry for the disconnected reply - I've been having news server issues, and
just switched to the mailing list instead>
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.
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.