How to get all the variables in a python shell

[Lie]

On Jun 2, 1:29 am, Lie <Lie.1... at gmail.com> wrote:
> lixinyi... at gmail.com wrote:
> > Hi!
>
> > I'm currently working on a scientific computation software built in
> > python.
> > What I want to implement is a Matlab style command window <->
> > workspace interaction.
>
> > For example, you type 'a=1' in the command window, and you see a list
> > item named 'a' in the workspace.
> > You double click the icon of the item, and you see its value. You can
> > modify the value of the list item,
> > 1 -> 100 etc,  after which if you go back to the command window and
> > type 'a'  and press enter, you see that
> > varable a's value has been changed to 100.
>
> > So my question is : if you have two DOS command windows running under
> > WINDOWS OS, how can you make them share the same internal variable
> > buffer? Or is there any easier way to implement such kind of
> > interaction?
>
> > Maybe I could just build a small database to store all the values and
> > access them from both programs, but chances are sometimes I have to
> > deal with big arrays, and they will eat extra memory if I keep them in
> > a database. Is there anyway to access a shell's local memory buffer?
> > I tried to use shell.interp.locals() in wxPython, but there's too many
> > variables in the list which I don't actually need.
>
> > Come on guys, give me some ideas. Thanks in advance!
>
> In all kinds of code, it's best to seperate the workers code and the
> UI code, in your case, you should create a backend (worker), which is
> a class that stands on its own, and two foreground class (UI) that is
> completely independent of each other but have the same interface. The
> backend code would have an event that is raised when it is changed to
> notify the UI (esp. The gui one) that it has changed since last time,
> possibly passing info on what have been changed. The front ends, would
> watch for this event as necessary (I don't think it is necessary for
> the command line to watch this event) and react to it as necessary
> like refreshing the view. The front-end window may only call functions
> on the backend to interact with the data being worked on (in short the
> backend class is opaque).
>
> This obliviate the need to share data between the two (or more)
> windows (UI) because all the data are contained in the backend class
> that the frontend can't access directly.

To clarify what I meant, the front ends should never contain any
working data except the ones needed for the UI to illustrate what it
wanted to show at the moment, and even then, it is accessed in read
only fashion.

And actually because of Python's Global Interpreter Lock, which means
that your program would all be contained in the same python
interpreter instance (unless you do some workarounds), passing objects/
lists around between python program is cheap because they're just a
"reference" passing (like pointer passing in C/C++)

This approach is a simple "server-client" method (not a true server-
client method though, since a true one cannot share unserialized
data), and is extremely scalable, it's easy to add a third window for
example, there is no need for every front end to be aware that there
are other front ends, since it just watches for the "Changed" event
from the backend.