[Tutor] variable within function retains value

[karma]

Hi All,

I'm trying to write a function that flattens a list. However after I
call the function more than once, it appends the result (a list) from
the second call with the first. I can get around it by either setting
the list to an empty one before calling the function, but I would like
to keep it in the function, another alternative I found was to pass an
empty list as an argument.

Can someone explain how python keeps track of variables within
functions (I was expecting the variable to be destroyed after a value
was returned). Also what is a better way to handle this?

Thanks


>>> def flatten(myList,start=[]):
    """ Flatten nested lists
    >>> flatten([1,[2,[3,4],5]],[])
    [1, 2, 3, 4, 5]
    """
    for i in myList:
        if type(i) != list:
            start.append(i)
        else: flatten(i,start)
    return start


>>> flatten([1,[2,[3,4],5]])
[1, 2, 3, 4, 5]

>>> flatten([1,[2,[3,4],5]])
[1, 2, 3, 4, 5, 1, 2, 3, 4, 5]

>>> flatten([1,[2,[3,4],5]],[])
[1, 2, 3, 4, 5]

2009/6/18 Luke Paireepinart <rabidpoobear at gmail.com>:
> Karen Palen wrote:
>>
>> Which appears to be merely the return code, not the stdout!
>>
>> It looks like I need to set some variable in IDLE, but I can't figure out
>> exactly what is needed here.
>>
>> Can anyone point me to an answer?
>>
>
> Well, Karen, according to my IDLE (admittedly it's 2.6 not 3.0 so it may not
> agree), call only returns the return code.
> You can check on your system by doing the following:
>
> IDLE 2.6.2     >>> import subprocess
>>>> help(subprocess.call)
>
> which will print out the docstring for the method:
>
> Help on function call in module subprocess:
>
> call(*popenargs, **kwargs)
>   Run command with arguments.  Wait for command to complete, then
>   return the returncode attribute.
>     The arguments are the same as for the Popen constructor.  Example:
>     retcode = call(["ls", "-l"])
>
> I believe what's happening is that you are confused about the presence of
> STDOUT in IDLE.
>
> In a normal console window, when you call a program (such as "ls"), stdout
> is directed at the screen (the console window.)
> So what's happening in the first example (the non-idle one) is:
>
> open subprocess and execute an "ls" call
>   - the subprocess prints out the result of the "ls" call
>   -subprocess finishes
> process finishes
>
> Now the key here is that in this case, both of these have the same stdout
> (the screen), which is the default stdout.
>
> However, when you run from an IDLE prompt, your stdout is not going to be
> the default.
> check it out if you want:
>
>>>> import sys
>>>> print sys.stdout
> <idlelib.rpc.RPCProxy object at 0x01198F90>
>
> Notice that this is not a standard stdout.
> In a normal Python window,
>
>>>> import sys
>>>> print sys.stdout
> <open file '<stdout>', mode 'w' at 0x00A43070>
>
> it's not the same stdout as IDLE has.
>
> So what's happening when you run the command from IDLE:
> open subprocess and execute an "ls" call
>   -subprocess starts, executes "ls", prints result to _its_ stdout (which is
> not IDLE's stdout, remember!)
>   -subprocess executes, output goes bye bye
> your process ends as well
>
> So the problem is that the stdout of the "ls" command is appearing in some
> location that you cannot see.
> As for ways to remedy this - I don't know.  The idea here, though, is that
> even though the regular Python version has the side-effect that it outputs
> it in the console, that's not necessarily what you want it to do.  The
> reason is that you have no way to access that data.
>
> Also you mentioned that IDLE prints out a 0.  This is only something that
> IDLE's interpreter does.
> For example
>>>> x = "hello"
>>>> x
> 'hello'
>
> IDLE echoes the value of x.  However, if you had the code
> x = "hello"
> x
>
> and you ran it (not in IDLE's interpreter) you would not get any output.
>
> What you should learn from this is
> 1- IDLE is weird in many ways
> 2 - that subprocess.call() is not meant to get data back from a call (look
> at subprocess.Popen and its communicate() method for that)
> 3 - sometimes things that appear to be outputs are side-effects/artifacts of
> the environment you're running them in and can't be depended upon.
>
> HTH,
> -Luke
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
>