[IronPython] Loading Python modules from Silverlight Isolated Storage

[Dino Viehland]

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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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"
>>>>> <curt at hagenlocher.org <mailto:curt at hagenlocher.org>
>>>>> <mailto:curt at hagenlocher.org> <mailto:curt at hagenlocher.org>> 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
>>>>>> <xkenneth at gmail.com <mailto:xkenneth at gmail.com>
>>>>>> <mailto:xkenneth at gmail.com> <mailto:xkenneth at gmail.com>> 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 at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>>>> <mailto:Users at lists.ironpython.com>
>>>>>> <mailto:Users at lists.ironpython.com>
>>>>>>   http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>>>> <mailto:Users at lists.ironpython.com>
>>>>>> <mailto:Users at lists.ironpython.com>
>>>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>>> <mailto:Users at 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 at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com <mailto:Users at 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 at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at 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 at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com