Ticket #24 (closed defect: wontfix)

Opened 11 months ago

Last modified 4 months ago

patch to rewrite.py to allow passing a context to output handler

Reported by: walters@verbum.org Assigned to:
Priority: blocker Keywords:
Cc:

Change History

08/10/08 21:11:12 changed by otaylor

  • status changed from new to closed.
  • resolution set to wontfix.

Cut-and-pasting from:

http://groups.google.com/group/reinteract/browse_thread/thread/6df95b8dfefa7ee3

Colin:

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.

Owen:

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

globalglobal_func? = some_func localsself? = some_object compiled, _ = rewrite_and_compile(code,

output_func_name='global_func', output_func_self='self')

exec compiled in locals, globals

And

localslocal_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.)

Colin:

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.