Question

What is the design pattern behind python like interactive shell. I want to do this for my server but I am ending up with lot of if - then- else pattern.

For example, when I start python interpreter I get something like this

Python 2.6.7 (r267:88850, Feb  2 2012, 23:50:20)
[GCC 4.5.3] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> help

After help the prompt changes to help

Welcome to Python 2.6!  This is the online help utility.

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://docs.python.org/tutorial/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, or topics, type "modules",
"keywords", or "topics".  Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as "spam", type "modules spam".

help>

I think this is some king of read-eval loop design.

Answer 1

for a REPL, you need a context (an object which stores the REPL’s state), a command parser (which parses input and produces an AST), and a way to map commands to actions (actions are generally just functions that modifies the context and/or produces side effects).

A simple REPL can be implemented like the following, where context is implemented using a simple dictionary, AST is just the inputted commands split on whitespaces, and a dictionary is used to map commands to actions:

context = {}
commands = {}

def register(func):
    """ convenience function to put `func` into commands map """
    # in C++, you cannot introspect the function's name so you would
    # need to map the function name to function pointers manually
    commands[func.__name__] = func
def parse(s):
    """ given a command string `s` produce an AST """
    # the simplest parser is just splitting the input string,
    # but you can also produce use a more complicated grammer
    # to produce a more complicated syntax tree
    return s.split()
def do(cmd, commands, context):
    """ evaluate the AST, producing an output and/or side effect """
    # here, we simply use the first item in the list to choose which function to call
    # in more complicated ASTs, the type of the root node can be used to pick actions
    return commands[cmd[0]](context, cmd)

@register
def assign(ctx, args):
    ctx[args[1]] = args[2]
    return '%s = %s' % (args[1], args[2])
@register
def printvar(ctx, args):
    print ctx[args[1]]
    return None
@register
def defun(ctx, args):
    body = ' '.join(args[2:])
    ctx[args[1]] = compile(body, '', 'exec')
    return 'def %s(): %s' % (args[1], body)
@register
def call(ctx, args):
    exec ctx[args[1]] in ctx
    return None
# more commands here

context['PS1'] = "> "
while True:
    # READ
    inp = raw_input(context["PS1"])

    # EVAL
    cmd = parse(inp)
    out = do(cmd, commands, context)

    # PRINT
    if out is not None: print out

    # LOOP

A sample session:

> assign d hello
d = hello
> printvar d
hello
> assign PS1 $
PS1 = $
$defun fun print d + 'world'
def fun(): print d + 'world'
$call fun
helloworld

with a little bit more trickery, you could even merge the context and commands dictionary together, allowing the shell’s set of commands to be modified in the shell’s language.

The name of this design pattern, if it has a name, is Read-Eval-Print Loop design pattern; so yeah, your question sorta answers itself.