Another option, assuming it's possible, would be to exec the function
definition as well as the lambda.
Also I would expect exec ... in locals() would work the same as "in
dict(locals())". Which might also be problematic if you expect to see changes
in the closure:
def f():
a = 1
d = dict(locals())
g = lambda: a
#exec 'g = lambda: a' in d
#print d['g']()
print g()
a = 2
#print d['g']()
print g()
But bringing this back to the original problem - trying to provide storage for
modules. There I don't think this should be a problem. Modules don't have an
outer function body to mess up the closure semantics so if you really want just
plain old module semantics creating a module and execing some code in its
dictionary should always give you the right behavior.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Tuesday, November 04, 2008 7:12 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Loading Python modules from Silverlight Isolated
Storage
Kenneth Miller wrote:
> Thanks for the reply.
>
> Would you mind elaborating?
Execing explicitly in locals solves the problem for Python 2.6:
>>> def f():
... a = 1
... exec 'g = lambda: a' in locals()
... return g
...
>>> g = f()
>>> g()
1
>>>
I don't think this would work in Python 3.0 though.
See this discussion on Python-dev for some of the issues:
http://mail.python.org/pipermail/python-dev/2008-October/082938.html
Michael
>
> Regards,
> Ken
>
> On Nov 4, 2008, at 8:47 AM, Michael Foord wrote:
>
>> Kenneth Miller wrote:
>>> All,
>>>
>>> The problem is illustrated here:
>>>
>>> This code will work properly:
>>>
>>> http://paste.pocoo.org/show/90071/
>>>
>>> This code produces an error:
>>>
>>> http://paste.pocoo.org/show/90072/
>>
>> Different issue. Exec'ing explicitly inside a namespace avoids that
>> problem altogether.
>>
>> Michael
>>
>>>
>>> Regards,
>>> Ken
>>>
>>> On Nov 4, 2008, at 4:42 AM, Michael Foord wrote:
>>>
>>>> Kenneth Miller wrote:
>>>>> It was proven to me that while exec might work for simple cases,
>>>>> more advanced usage (declaring a lambda function inside an exec)
>>>>> can be problematic. It was advised that I generate python modules
>>>>> and dynamically import them. If memory served me, it's not
>>>>> possible to import a module from a string object.
>>>>>
>>>> I have often generated (or loaded code into a string) and then
>>>> exec'd it into a module dict to create modules at runtime. It is a
>>>> relatively normal technique in Python.
>>>>
>>>> Michael
>>>>
>>>>> Thanks.
>>>>>
>>>>> - Ken
>>>>>
>>>>> On Nov 4, 2008, at 12:45 AM, "Curt Hagenlocher"
>>>>> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>>>>> <mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]>> wrote:
>>>>>
>>>>>> You should be able to do this all in-memory:
>>>>>>
>>>>>> >>> import sys
>>>>>> >>> foo = type(sys)('foo')
>>>>>> >>> sys.modules['foo'] = foo
>>>>>> >>> exec 'a = 1' in foo.__dict__
>>>>>> >>> foo.a
>>>>>> 1
>>>>>> >>>
>>>>>>
>>>>>> There's probably a better ("more Pythonic") way to do this, but
>>>>>> I'm sleepy...
>>>>>>
>>>>>> On Mon, Nov 3, 2008 at 11:40 PM, Kenneth Miller
>>>>>> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>>>>>> <mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]>> wrote:
>>>>>>
>>>>>> All,
>>>>>>
>>>>>> Is it possible to have python load modules from the silverlight
>>>>>> isolated storage? My app needs to dynamically generate and import
>>>>>> python code to run.
>>>>>>
>>>>>> Regards,
>>>>>> Ken
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users@lists.ironpython.com <mailto:Users@lists.ironpython.com>
>>>>>> <mailto:Users@lists.ironpython.com>
>>>>>> <mailto:Users@lists.ironpython.com>
>>>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users@lists.ironpython.com <mailto:Users@lists.ironpython.com>
>>>>>> <mailto:Users@lists.ironpython.com>
>>>>>> <mailto:Users@lists.ironpython.com>
>>>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users@lists.ironpython.com <mailto:Users@lists.ironpython.com>
>>>>> <mailto:Users@lists.ironpython.com>
>>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>>
>>>>
>>>>
>>>> --
>>>> http://www.ironpythoninaction.com/
>>>> http://www.voidspace.org.uk/blog
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users@lists.ironpython.com <mailto:Users@lists.ironpython.com>
>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users@lists.ironpython.com <mailto:Users@lists.ironpython.com>
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>
>>
>> --
>> http://www.ironpythoninaction.com/
>> http://www.voidspace.org.uk/blog
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users@lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
