Hello all,
I am not sure this is the correct list to ask as my problem is really
related to python low level implementation, but as I do not have found a
python.dev list, here it is :-)
We are curently developing python bindings to make a MPI parallel
application (Finite element solver) script driven. I have written a main
interpreter, able to execute scripts or interractive commands,in // ,
based on the following techniques:
*file execution: all python interpreter processes run the file using
PyRun_SimpleFil e (file must be available to all processes)
*file execution using broadcast: process 0 read input file and store it in
a file, broadcast it to all processes and the script is run using
PyRun_SimpleStr ing (file must be available to process 0 only)
*interractive execution: All processes listen to user input using a
PyRun_Interacti veLoop. Process 0 read stdin and broadcast the line to all
process, the other process listen to this broadcast. This is implemented
using the (very usefull in this case :-) ) PyOS_ReadlineFu nctionPointer ,
reassigning it to an input function which wrap the default
PyOS_ReadlineFu nctionPointer (to be able to reuse nice readline
functionalities ) and add the broadcasting mechanism...
All of this work perfectly, but I had to modify the python sources,
Parser/myreadline.c to be precise... Indeed, the behavior of PyOS_Readline
is to use the user-modifiable PyOS_ReadlineFu nctionPointer as input
mechanism, except when input is non-interractive in which case it fall
back to the non-user-modifiable PyOS_StdioReadl ine...As my processes are
non-interractive except for proc 0 (launched in background), proc 0
broadcast but the other ones do not listen. I thus had to remove this
test, so that the user-modifiable function is called in all cases.
/*Python code snipped from Parser/myreadline.c*/
char *
PyOS_Readline(F ILE *sys_stdin, FILE *sys_stdout, char *prompt) {
char *rv;
if (PyOS_ReadlineF unctionPointer == NULL) {
#ifdef __VMS
PyOS_ReadlineFu nctionPointer = vms__StdioReadl ine;
#else
PyOS_ReadlineFu nctionPointer = PyOS_StdioReadl ine;
#endif
}
}
Py_BEGIN_ALLOW_ THREADS
/* This is needed to handle the unlikely case that the
* interpreter is in interactive mode *and* stdin/out are not * a
tty. This can happen, for example if python is run like * this:
python -i < test1.py
*/
/* my modif: comment out the use of PyOS_StdioReadl ine for
non-interractive input...*/
/*if (!isatty (fileno (sys_stdin)) || !isatty (fileno(sys_std out)))
rv = PyOS_StdioReadl ine (sys_stdin, sys_stdout, prompt);
else*/
rv = (*PyOS_Readline FunctionPointer )(sys_stdin,
sys_stdout,
prompt);
Py_END_ALLOW_TH READS
return rv;
}
}
/*end of snipped code*/
This is a small modif, but annoying because we would prefer to use the
plain python distribution, and anyway I wonder if the current behavior of
python is desirable, because basically it removes part of the
functionality of PyOS_ReadlineFu nctionPointer: flexibility dissapear for
non-interractive input.
In addition, this seems not so robust, it seems to me that it is not
correct for vms, where PyOS_StdioReadl ine will be used in non-interractive
case while vms__StdioReadl ine will be used for interractive one....maybe
this is the intended behavior, but then the function naming is strange :-)
So basically, shouldn't it be the resposability of the code which change
PyOS_ReadlineFu nctionPointer to check if the function given is adapted to
interractivenes s of input? this seems the more flexible approach, and
probably involve only minor modif of the readline module.
In addition, wouldn't it be nice to initialize PyOS_ReadlineFu nctionPointer
to a default value (suitable reading function) at declaration, instead of
defining it to NULL and let PyOS_Readline do the initialization when
needed?
This way, user code can get back a meaningfull reading function
storing the old value of PyOS_ReadlineFu nctionPointer, use it to write an
extended input function, and reasign it to PyOS_ReadlineFu nctionPointer.. .
This seems to me like the most flexible way to add user-tunable input
method...
So, to all experienced python developers, having used this
PyOS_ReadlineFu nctionPointer
function or implemented this code, what do you think of these possible slight
modifications? Or is there a better way to use it than my current method?
Sorry for the long (and possibly strangely written, english is not my
native language :-) ) post,
Best reagards,
Greg.
I am not sure this is the correct list to ask as my problem is really
related to python low level implementation, but as I do not have found a
python.dev list, here it is :-)
We are curently developing python bindings to make a MPI parallel
application (Finite element solver) script driven. I have written a main
interpreter, able to execute scripts or interractive commands,in // ,
based on the following techniques:
*file execution: all python interpreter processes run the file using
PyRun_SimpleFil e (file must be available to all processes)
*file execution using broadcast: process 0 read input file and store it in
a file, broadcast it to all processes and the script is run using
PyRun_SimpleStr ing (file must be available to process 0 only)
*interractive execution: All processes listen to user input using a
PyRun_Interacti veLoop. Process 0 read stdin and broadcast the line to all
process, the other process listen to this broadcast. This is implemented
using the (very usefull in this case :-) ) PyOS_ReadlineFu nctionPointer ,
reassigning it to an input function which wrap the default
PyOS_ReadlineFu nctionPointer (to be able to reuse nice readline
functionalities ) and add the broadcasting mechanism...
All of this work perfectly, but I had to modify the python sources,
Parser/myreadline.c to be precise... Indeed, the behavior of PyOS_Readline
is to use the user-modifiable PyOS_ReadlineFu nctionPointer as input
mechanism, except when input is non-interractive in which case it fall
back to the non-user-modifiable PyOS_StdioReadl ine...As my processes are
non-interractive except for proc 0 (launched in background), proc 0
broadcast but the other ones do not listen. I thus had to remove this
test, so that the user-modifiable function is called in all cases.
/*Python code snipped from Parser/myreadline.c*/
char *
PyOS_Readline(F ILE *sys_stdin, FILE *sys_stdout, char *prompt) {
char *rv;
if (PyOS_ReadlineF unctionPointer == NULL) {
#ifdef __VMS
PyOS_ReadlineFu nctionPointer = vms__StdioReadl ine;
#else
PyOS_ReadlineFu nctionPointer = PyOS_StdioReadl ine;
#endif
}
}
Py_BEGIN_ALLOW_ THREADS
/* This is needed to handle the unlikely case that the
* interpreter is in interactive mode *and* stdin/out are not * a
tty. This can happen, for example if python is run like * this:
python -i < test1.py
*/
/* my modif: comment out the use of PyOS_StdioReadl ine for
non-interractive input...*/
/*if (!isatty (fileno (sys_stdin)) || !isatty (fileno(sys_std out)))
rv = PyOS_StdioReadl ine (sys_stdin, sys_stdout, prompt);
else*/
rv = (*PyOS_Readline FunctionPointer )(sys_stdin,
sys_stdout,
prompt);
Py_END_ALLOW_TH READS
return rv;
}
}
/*end of snipped code*/
This is a small modif, but annoying because we would prefer to use the
plain python distribution, and anyway I wonder if the current behavior of
python is desirable, because basically it removes part of the
functionality of PyOS_ReadlineFu nctionPointer: flexibility dissapear for
non-interractive input.
In addition, this seems not so robust, it seems to me that it is not
correct for vms, where PyOS_StdioReadl ine will be used in non-interractive
case while vms__StdioReadl ine will be used for interractive one....maybe
this is the intended behavior, but then the function naming is strange :-)
So basically, shouldn't it be the resposability of the code which change
PyOS_ReadlineFu nctionPointer to check if the function given is adapted to
interractivenes s of input? this seems the more flexible approach, and
probably involve only minor modif of the readline module.
In addition, wouldn't it be nice to initialize PyOS_ReadlineFu nctionPointer
to a default value (suitable reading function) at declaration, instead of
defining it to NULL and let PyOS_Readline do the initialization when
needed?
This way, user code can get back a meaningfull reading function
storing the old value of PyOS_ReadlineFu nctionPointer, use it to write an
extended input function, and reasign it to PyOS_ReadlineFu nctionPointer.. .
This seems to me like the most flexible way to add user-tunable input
method...
So, to all experienced python developers, having used this
PyOS_ReadlineFu nctionPointer
function or implemented this code, what do you think of these possible slight
modifications? Or is there a better way to use it than my current method?
Sorry for the long (and possibly strangely written, english is not my
native language :-) ) post,
Best reagards,
Greg.