patch to rewrite.py to pass context

[Colin Walters]

Hi,

This patch to rewrite.py allows us to pass a context variable into the
output function, which allows us to avoid manipulating the global
scope in the way worksheet.py does. This was necessary for my program
because it's threaded. I didn't make the change to worksheet.py to
use this, but it should be easy.

http://cdn.verbum.org/reinteract-rewrite-to-global.patch

[Owen Taylor]

On Jan 14, 2008 8:07 PM, Colin Walters <cgwa...@gmail.com> wrote:
>
> Hi,
>
> This patch to rewrite.py allows us to pass a context variable into the
> output function, which allows us to avoid manipulating the global
> scope in the way worksheet.py does. This was necessary for my program
> because it's threaded. I didn't make the change to worksheet.py to
> use this, but it should be easy.

I'm not fundamentally opposed to the patch, but what's the difference between:

global['global_func'] = some_func
locals['self'] = some_object
compiled, _ = rewrite_and_compile(code,
output_func_name='global_func', output_func_self='self')
exec compiled in locals, globals

And

locals['local_func'] = lambda *args: some_func(some_object, *args)
compiled, _ = rewrite_and_compile(code, output_func_name=local_func)
exec compiled in locals, globals

Also, why would multiple threads would be sharing the same global
scope? (There are obviously cases where that happens, like when
multiple threads are using the same module. But I wouldn't expect one
to use the compiled result of rewrite.py with the global scope of a
module.)

- Owen

[Colin Walters]

On Jan 15, 8:38 am, "Owen Taylor" <owtay...@gmail.com> wrote:
>
> Also, why would multiple threads would be sharing the same global
> scope?

Ah, I misunderstood what the global scope is in Python, I guess. So
it should actually be safe to have multiple threads using the previous
code as-is then.