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 <rabidpoob...@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 - tu...@python.org > http://mail.python.org/mailman/listinfo/tutor > _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor