On Sep 12, 10:05 am, [EMAIL PROTECTED] (Alex Martelli) wrote:
...
> into a function and a call to it:
>
> def f():
> with implicit_self(t):
> print a
> print b
> a = 40
> b = a * 2
> f()
>
> ...even with different values for the argument to _getframe. You just
> can't "dynamically" add local variables to a function, beyond the set
> the compiler has determined are local (and those are exactly the ones
> that are *assigned to* in the function's body -- no less, no more --
> where "assigned to" includes name-binding statements such as 'def' and
> 'class' in addition to plain assignment statements, of course).
>
> Making, say, 'a' hiddenly mean 'x.a', within a function, requires a
> decorator that suitably rewrites the function's bytecode... (after
> which, it WOULD still be terrible and horrible and not to be used, just
> as you say, but it might at least _work_;-). Main problem is, the
> decorator needs to know the set of names to be "faked out" in this
> terrible and horrible way at the time the 'def' statement executes: it
> can't wait until runtime (to dynamically determine what's in var(self))
> before it rewrites the bytecode (well, I guess you _could_ arrange a
> complicated system to do that, but it _would_ be ridiculously slow).
>
> You could try defeating the fundamental optimization that stands in your
> way by adding, say,
> exec 'pass'
> inside the function-needing-fakeouts -- but we're getting deeper and
> deeper into the mire...;-)
What about abusing 'import' like this:
def f():
with implicit_self(t):
sys.modules['__the_mire__'] = t
from __the_mire__ import a, b
print a
print b
a = 40
b = a * 2
If the list of attributes is long then
'import' can save some typing compared to
a = self.a
b = self.b
...
z = self.z
--
Regards,
Steven
--
http://mail.python.org/mailman/listinfo/python-list
