It's somewhat common knowledge that Python functions can have a maximum of 256 arguments. What I'm curious to know is if this limit applies to *args
and **kwargs
when they're unrolled in the following manner:
items = [1,2,3,4,5,6]
def do_something(*items):
pass
I ask because, hypothetically, there might be cases where a list larger than 256 items gets unrolled as a set of *args
or **kwargs
.
In versions before Python 3.7, CPython has a limit of 255 explicitly passed arguments in a call:
This limitation is in place because until Python 3.5, the
CALL_FUNCTION
opcode overloaded the opcode argument to encode both the number of positional and keyword arguments on the stack, each encoded in a single byte.This limitation is removed in the upcoming Python 3.7 release, see issue #27213 and issue #12844; #27213 reworked the
CALL_FUNCTION*
family of opcodes for performance and simplicity (part of 3.6), freeing up the opcode argument to only encode a single argument count, and #12844 removed the compile-time check that prevented code with more arguments from being compiled.In 3.7, with the
EXTENDED_ARG()
opcode, there is now no limit at all on how many arguments you can pass in using explicit arguments, save how many can be fitted onto the stack (so bound now by your memory):Do note that lists, tuples and dictionaries are limited to
sys.maxsize
elements, so if the called function uses*args
and/or**kwargs
catch-all parameters then those are limited.For the
*args
and**kwargs
call syntax (expanding arguments) there are no limits other than the samesys.maxint
size limits on Python standard types.WFM
Update: as Brian noticed, the limit is on the calling side:
on the other hand this works:
Conclusion: no, it does not apply to unrolled arguments.
This appears to be a restriction in compiling the source, so will probably exist only for arguments being passed directly, not in *args or **kwargs.
The relevant code can be found in ast.c:
But note that this is in ast_for_call, and so only applys to the calling side. ie
f(a,b,c,d,e...)
, rather than the definition, though it will count both positional(a,b,c,d)
andkeyword (a=1, b=2, c=3)
style parameters . Actual*args
and**kwargs
parameters look like they should only count as one argument for these purposes on the calling side.The limit is due to how the compiled bytecode treats calling a function with position arguments and/or keyword arguments.
The bytecode op of concern is
CALL_FUNCTION
which carries anop_arg
that is 4 bytes in length, but on the two least significant bytes are used. Of those, the most significant byte represent the number of keyword arguments on the stack and the least significant byte the number of positional arguments on the stack. Therefore, you can have at most0xFF == 255
keyword arguments or0xFF == 255
positional arguments.This limit does not apply to
*args
and**kwargs
because calls with that grammar use the bytecode opsCALL_FUNCTION_VAR
,CALL_FUNCTION_KW
, andCALL_FUNCTION_VAR_KW
depending on the signature. For these opcodes, the stack consists of an iterable for the*args
and adict
for the**kwargs
. These items get passed directly to the receiver which unrolls them as needed.I tried for a list of 4000 items, and it worked. So I'm guessing it will work for larger values as well.
for **kwargs, If I remember well, this is a dictionary. It therefore has about no limits.
for *args, I am not so sure, but I think it is a tuple or a list, so it also has about no limits.
By no limits, I mean except maybe the memory limit.