controlling input behavior of embedded python with PyOS_ReadlineFunctionPointer

Discussion in 'Python' started by Gregory Lielens, May 13, 2004.

  1. 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_SimpleFile (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_SimpleString (file must be available to process 0 only)

    *interractive execution: All processes listen to user input using a
    PyRun_InteractiveLoop. 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_ReadlineFunctionPointer ,
    reassigning it to an input function which wrap the default
    PyOS_ReadlineFunctionPointer (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_ReadlineFunctionPointer as input
    mechanism, except when input is non-interractive in which case it fall
    back to the non-user-modifiable PyOS_StdioReadline...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(FILE *sys_stdin, FILE *sys_stdout, char *prompt) {
    char *rv;

    if (PyOS_ReadlineFunctionPointer == NULL) {
    #ifdef __VMS
    PyOS_ReadlineFunctionPointer = vms__StdioReadline;
    #else
    PyOS_ReadlineFunctionPointer = PyOS_StdioReadline;
    #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_StdioReadline for
    non-interractive input...*/
    /*if (!isatty (fileno (sys_stdin)) || !isatty (fileno(sys_stdout)))
    rv = PyOS_StdioReadline (sys_stdin, sys_stdout, prompt);
    else*/
    rv = (*PyOS_ReadlineFunctionPointer)(sys_stdin,
    sys_stdout,
    prompt);
    Py_END_ALLOW_THREADS
    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_ReadlineFunctionPointer: 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_StdioReadline will be used in non-interractive
    case while vms__StdioReadline 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_ReadlineFunctionPointer to check if the function given is adapted to
    interractiveness 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_ReadlineFunctionPointer
    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_ReadlineFunctionPointer, use it to write an
    extended input function, and reasign it to PyOS_ReadlineFunctionPointer...
    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_ReadlineFunctionPointer
    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.
    Gregory Lielens, May 13, 2004
    #1
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Holger (David) Wagner
    Replies:
    1
    Views:
    533
  2. Mario Figueiredo
    Replies:
    1
    Views:
    397
    Jack Klein
    Nov 16, 2006
  3. Jeff Rollin

    Controlling input?

    Jeff Rollin, Jun 7, 2007, in forum: C++
    Replies:
    4
    Views:
    279
    Jeff Rollin
    Jun 7, 2007
  4. Amir Hardon
    Replies:
    1
    Views:
    78
    Amir Hardon
    Feb 28, 2004
  5. shaj
    Replies:
    1
    Views:
    91
    Thomas 'PointedEars' Lahn
    Jul 27, 2009
Loading...

Share This Page