Why does *args argument unpacking give a tuple?

user_10876060 0
Viewed 1610

In python, it is possible to define a function taking an arbitrary number of positional arguments like so:

def f(*args):
    print(args)
f(1, 2, 3)  # (1, 2, 3)

When called as f(a, b, c), all positional arguments are put together into a tuple. This behavior is described in python 2 and 3 documentation, but I haven't found a PEP to it.

PEP 3132, introducing extended iterable unpacking (first, *middle, last = seqence) states under "Acceptance" that

Make the starred target a tuple instead of a list. This would be consistent with a function's *args, but make further processing of the result harder.

was discussed. If I write a wrapper, I may also want to further process arguments like so:

def force_type(position, type):
    def wrapper(f):
        def new(*args, **kwargs):
            args = list(args)  # Why?
            args[position] = type(args[position])
            return f(*args, **kwargs)
        return new
    return wrapper

@force_type(1, int)
def func(a, b, c):
    assert isinstance(b, int)

This further processing is made harder by the fact args is a tuple. Were wrappers just not used at the early stages this was introduced? If so, why wasn't this changed in python3 with other compatibility breaking changes (PEP3132 favours ease of processing over consistency (which seems at least similar to compatibility in a compatibility- breaking change).

Why are a functions *args (still) a tuple even though a list allows easier further processing?

arguments function python
3 Answers

I don't know if this was the thinking behind it, but that ease of processing (even though instantiate a list with the tuple data is not that hard) would come at possible confusing behavior.

def fce1(*args):
   fce2(args)
   # some more code using args

def fce2(args):
   args.insert(0, 'other_val')

fce1(1, 2, 3)

Could surprise people writing fce1 code not realizing that args they deal with later on are not what the function was called with.

I would also presume immutable types are easier to deal with internally and come with less overhead.

user_92882000

Why not? The thing about tuple is, that you can not change it after creation. This allows to increase speed of executing your script, and you do not really need a list for your function arguments, because you do not really need to modify the given arguments of a function. Would you need append or remove methods for your arguments? At most cases it would be no. Do you want your program run faster. That would be yes. And that's the way the most people would prefer to have things. The *args thing returns tuple because of that, and if you really need a list, you can transform it with one line of code!

args = list(args)

So in general: It speeds up your program execution. You do not it to change the arguments. It is not that hard to change it's type.

user_108973070

My best guess would be that if *args generates a list(mutable), it can lead to very surprising results for a multitude of situations. @Ondrej K. has given a great example. As an analogy, when having a list as a default argument, every function call might have different default arguments. This is the result of default arguments being evaluated only once, and this situation is not the most intuitive. Even the official python docs have a specific workaround for this exact situation.

Default parameter values are evaluated from left to right when the function definition is executed. This means that the expression is evaluated once, when the function is defined, and that the same “pre-computed” value is used for each call. This is especially important to understand when a default parameter is a mutable object, such as a list or a dictionary: if the function modifies the object (e.g. by appending an item to a list), the default value is in effect modified. This is generally not what was intended. A way around this is to use None as the default, and explicitly test for it in the body of the function, e.g.:

def whats_on_the_telly(penguin=None):
if penguin is None:
    penguin = []
penguin.append("property of the zoo")
return penguin

Source documentation

To summarize, I believe that *args is a tuple because having it as a list would cause all the problems associated with a mutable type (like slower speed) and the bigger issue would be that most do not expect function arguments to change. Although I do agree that this implementation is very inconsistent with PEP-3132 and will cause confusion for most learners. I am very new to Python and it took me a while to understand what might be the reason for *args to be a tuple and not a list for the sake of consistency with PEP-3132's acceptance.

user_147310180
Related