[mdione at grulic.org.ar: modifying locals]

Marcos Dione mdione at grulic.org.ar
Mon Oct 12 03:27:38 EDT 2015


    I repost this here, as somebody in python-help told it was probably 
out of their league.

----- Forwarded message from Marcos Dione <mdione at grulic.org.ar> -----

Date: Sun, 11 Oct 2015 15:30:05 +0200
From: Marcos Dione <mdione at grulic.org.ar>
Subject: modifying locals
To: help at python.org
Message-ID: <20151011133005.GC2798 at diablo.grulicueva.local>
Content-Type: text/plain; charset=us-ascii


    First of all, I'm not subscribed to the list, so please CC me.

    I'm writing a language[1] heavily based on Python. The way I'm
implementing it is by having my own parser (based/stealed from pypy),
obtaining an AST, modifying it and running the result with exec(). 

    One of its particular features is that I intend to support
semi-transparent remote execution using paramiko. For that, there is a
construction that looks like this:


[local code 1]
with remote(...):
    [remote code]

[local code 2]


    The idea is that [remote code] is effectively executed in a remote
machine specified in remote()'s parameters. This is implemented[3] by
remote() being a context manager. Part of the transparency is that
globals and locals at the remote() point will be accesible to the remote
code (so far only variables), and that modifications to locals will be
visible back to [local code 2]. 

    So far I managed to do the first part, but not the second. I managed
to transfer the locals back from the remote. My problem is modifying the
locals in remote()'s __exit__() method. As I'm running the code using
exec(), it's not just a matter of modifying locals()[2].

    What I tried was the following:

* When I execute the code, I pass an empty dictionary to hold the locals.
  I save a reference to it, and I try to use it to modify the locals
  [local code 2] sees, but as locals are related to stack frame, it
  doesn't work.

* This leads to the second attempt: use the stack to modify remote()'s
  caller's locals by[4]:


inception_locals= sys._getframe().f_back.f_locals
inception_locals.update (locals)


  Somehow this doesn't work either, and it's driving me crazy. 

    I run out of ideas, so maybe you could throw some? Thanks in
advance.

--
[1] if you're interested, check https://github.com/StyXman/ayrton/

[2] isn't it? Just by writing that I got my doubts...

[3] https://github.com/StyXman/ayrton/blob/develop/ayrton/functions.py#L112

[4] https://github.com/StyXman/ayrton/blob/develop/ayrton/functions.py#L254
-- 
(Not so) Random fortune:
They called me mad, and I called them mad, and damn them, they outvoted me.
	    -- Nathaniel Lee

----- End forwarded message -----

-- 
(Not so) Random fortune:
Cruickshank's Law of Committees: If a committee is allowed to discuss a bad idea
long enough, it will inevitably decide to implement the idea simply because so
much work has already been done on it.



More information about the Python-list mailing list