Question

I was pondering one of my little tools I frequently use, and was thought about the plausibility of a self-building nest.

I often use
def reset (i, j, k):
i = 0
j = 0
k = 0
But the function is defined in this case for specifically 3 arguments. Is is possible or even worthwhile to define the function using a string and define a separate function to "refresh" the action the main function does, i.e. adding another nested action?

On a related note, is there a way to define the function in a way so as to have a variable number of arguments? As in reset(a, g, w, y, r)?

Answer 1

I didn't quite understand the first part of the question? Do you mean, like creating a string flag to restart a loop, or something like that? Maybe I am too sleepy so I couldn't understand it. Sorry, mate.
About the second question, I don't think you can define a function with variable numbers of arguments, but you can use OOP to make something of the like, or, I don't know to what extent this is good programming discipline, but I think you can use unpacking arguments keywords (**kwargs and *args), but I don't how good this would work, never really tried it a lot.

Answer 2

I don't think the first function does what you think it does. It will only change the values of the variables locally, which won't have any effect outside of the function. Because of that, it wouldn't make must sense to figure out how to make it take a variable number of arguments.

If you stored the values in a list, and passed the list to the function, then the function could change the values in the list, and those changes would be seen outside the function. You could also pass it a list of any length, thus solving the variable number of arguments problem, too.

Answer 3

dmancine, can you write something like a prompt to get a list (or get the list for somewhere else) and create a function with an unpacking argument, and then iterate through the list, I mean, for i in a: a[i] = 0? If that is feasible, I think it could work as a solution also, even though passing a list is definitely easier.

Answer 4

I don't quite understand what you mean by "refresh", but if you are trying to change the values of the variables in function reset with another user-defined function then resetting the values of the variables in the second function would not work because "variables inside a function does not make sense outside the function". Well, if you wish to be able to change the value at any point in any other function, you should define the variable to be global.

Answer 5

http://docs.python.org/tutorial/controlflow.html#more-on-defining-functions

This talks about all of it: default arguments, keyword arguments, keyword dictionaries (**keywords), arbitrary argument lists (*name), unpacking arguments, lambda forms, all of it.

But the fact remains, if you define a function to take an integer (or any immutable type) as a parameter, you can't modify its value outside the function. If the function takes a list (or any mutable type) you can modify its contents and have that be visible outside the function, but you can't change what list the parameter pointed to outside the function. A functions gets local references to values outside its own scope.

@bmp, is this what you're talking about?
http://codepad.org/Eoi2lMuZ
Arbitrary argument lists get packaged up into a tuple, so they're not mutable. Even if I created the arguments by unpacking a list.

Answer 6

@dmancine, Yes, precisely that. I noticed only later that they get packaged into a tuple. I read it on the Python docs, as I wasn't able to test it when I asked you. How useful is *args? One can unpack a command line argument, pretty much like atoi from C? Thanks for the info :-)

Answer 7

If you're familiar with C then you're probably familiar with printf. That's an excellent use of *args. You could rewrite it in python with something like

def printf(formatString, *args):
print formatString % (args)

Here it is in action: http://codepad.org/AjnHSB1j
Python already has a facility for printing formatted strings (actually it's more like sprintf because it gives you back the string) so it's not the best use of it. I haven't written any Python since learning about it, so I haven't seen any reason to use it yet. Maybe the language features of Python are such that it's not very useful.

Python doesn't have function overloading (defining multiple functions with the same name but different parameter lists), probably because arguments aren't typed, and you'd only be able to overload functions based on numbers of parameters, which is of only limited usefulness. Named parameters and default parameter values help make up for that shortcoming. You could also use *args to effectively overload functions, albeit in a tortuously awful way.

It would be best used in situations like printf, where you have a (possibly empty) list of truly arbitrary parameters. Though if the user is typing the arguments by hand, it wouldn't be much more trouble to surround them in parens, and you could handle it as a single tuple argument. You'd have to with *args, anyway.

So, that was kinda' rambling. After thinking about it, I guess the answer to how useful *args is is probably not very.

Answer 8

@dmancine Interesting point, albeit, as you said, a printf-like function isn't really useful in Python, but is a interesting usage of the *args nevertheless. Kudos for thinking about it.
At first, I thought about using *args coupled with sys.argv, in a particular case, suppose I want to implement a shell using Python, my first thoughts were using argv to get the string call for the function (sys.argv[0]) and then passing the rest of the list as a packed argument. Surely, implementing piping and conditionals are completely different stories, but nevertheless it was what came to my mind, but it doesn't seem that much interesting also. Maybe *args is, indeed, probably not very useful altogether. (Especially due to the existence of the fileinput library)

Answer 9

To a shell a command line looks like this:
[command name] [other stuff]
The shell really only cares about the first token. It assumes the actual handler for the command (whatever form that takes) will know how to use the "other stuff". So that's another good use for *args. The client (the shell command parser) gets an arbitrary sequence of arguments (arbitrary to *it* at least) and passes them to some handler. It doesn't gain anything by unpacking the list into separate arguments, and it wouldn't want to, because the handler wants to be able to accept a variable number of arguments.