Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Writing to function arguments during execution

1 view
Skip to first unread message

John O'Hagan

unread,
Oct 11, 2009, 9:18:25 AM10/11/09
to pytho...@python.org
I'm writing a (music-generating) program incorporating a generator function
which takes dictionaries as its arguments. I want to be able to change the
values of the arguments while the program is running. I have it working as in
this toy example (python 2.5):

from sys import argv
from threading import Thread
from my_functions import option_processor, work

#Make a dictionary of arguments to the main "work" function
argdict = option_processor(argv[1:])

def argdict_rewriter(argdict):
"""Write new values to a dictionary of arguments"""
while 1:
new_dict = option_processor(raw_input().split())
argdict.update(new_dict)

#Write to the dictionary while program is running
rewriter = Thread(target=argdict_rewriter, args=(argdict,))
rewriter.setDaemon(True)
rewriter.start()

#The main generator function
work(argdict)

Now I can change the output of the "work" function while it's running via
raw_input(). However it's very crude, not least because the terminal echo of
the new options is interspersed with the output of the program.

In future I hope to be able to have several instances of the "work" function
running as threads simultaneously, and to separately control the arguments to
each.

I think the general problem is how to send output from a thread to a different
place from that of its parent thread, but I'm not sure.

Is there a standard way to do this kind of thing? In particular, I'm after a
solution whereby I can enter new arguments in one terminal window and observe
the program's output in another.

Regards,

John

Rhodri James

unread,
Oct 11, 2009, 9:54:02 AM10/11/09
to pytho...@python.org
On Sun, 11 Oct 2009 14:18:25 +0100, John O'Hagan <rese...@johnohagan.com>
wrote:

> Now I can change the output of the "work" function while it's running via
> raw_input(). However it's very crude, not least because the terminal
> echo of
> the new options is interspersed with the output of the program.
>
> In future I hope to be able to have several instances of the "work"
> function
> running as threads simultaneously, and to separately control the
> arguments to
> each.
>
> I think the general problem is how to send output from a thread to a
> different
> place from that of its parent thread, but I'm not sure.
>
> Is there a standard way to do this kind of thing? In particular, I'm
> after a
> solution whereby I can enter new arguments in one terminal window and
> observe
> the program's output in another.

The standard way (if you don't want to write a GUI for the whole thing)
is to have separate programs communicating with sockets. Start your
music program in one terminal and the control program in the other,
and have a thread listening to the socket rather than using raw_input().

Exactly what processing your control program should do before tossing
the data through the socket is a matter of religious debate :-)

--
Rhodri James *-* Wildebeest Herder to the Masses

John O'Hagan

unread,
Oct 13, 2009, 10:29:41 PM10/13/09
to pytho...@python.org
On Mon, 12 Oct 2009, Rhodri James wrote:
> On Sun, 11 Oct 2009 14:18:25 +0100, John O'Hagan <rese...@johnohagan.com>
>
> wrote:
> > Now I can change the output of the "work" function while it's running via
> > raw_input(). However it's very crude, not least because the terminal
> > echo of
> > the new options is interspersed with the output of the program.
> >
> > In future I hope to be able to have several instances of the "work"
> > function
> > running as threads simultaneously, and to separately control the
> > arguments to
> > each.
> >
> > I think the general problem is how to send output from a thread to a
> > different
> > place from that of its parent thread, but I'm not sure.
> >
> > Is there a standard way to do this kind of thing? In particular, I'm
> > after a
> > solution whereby I can enter new arguments in one terminal window and
> > observe
> > the program's output in another.
>
> The standard way (if you don't want to write a GUI for the whole thing)
> is to have separate programs communicating with sockets. Start your
> music program in one terminal and the control program in the other,
> and have a thread listening to the socket rather than using raw_input().

Thanks, sockets are the way to go for this and surprisingly easy to use once
you get your head around them. I tried Rhodri's suggested approach but for now
I used the original terminal for both starting the program and entering new
options (still via raw_input) and a new terminal listening on a socket
connection to display the results.

A secondary question: right now I'm starting the "listening" terminal by
executing a script ('display.py') as a subprocess:

port = 50007
here = os.path.abspath('')
terminal = os.environ['TERM']
subprocess.Popen([terminal, '-e', here + '/display.py', str(port)])

but to me it feels kind of clunky to have a separate script just for this; is
there a nicer way to launch another terminal, say by passing a locally defined
function to it?

Regards,

John

Dave Angel

unread,
Oct 14, 2009, 6:19:07 AM10/14/09
to John O'Hagan, pytho...@python.org
John O'Hagan wrote:
> <snip>

> Thanks, sockets are the way to go for this and surprisingly easy to use once
> you get your head around them. I tried Rhodri's suggested approach but for now
> I used the original terminal for both starting the program and entering new
> options (still via raw_input) and a new terminal listening on a socket
> connection to display the results.
>
> A secondary question: right now I'm starting the "listening" terminal by
> executing a script ('display.py') as a subprocess:
>
> port = 50007
> here = os.path.abspath('')
> terminal = os.environ['TERM']
> subprocess.Popen([terminal, '-e', here + '/display.py', str(port)])
>
> but to me it feels kind of clunky to have a separate script just for this; is
> there a nicer way to launch another terminal, say by passing a locally defined
> function to it?
>
> Regards,
>
> John
>
>
You could pass it the same script you're running, but with a
command-line argument that causes it to execute a different part of the
script. Perhaps the port parameter above is enough, as your main
process won't be getting that argument. I'd recommend something
explicit, however.

DaveA

0 new messages