[Python-ideas] New 3.x restriction on number of keyword arguments
solipsis at pitrou.net
Fri Sep 17 23:11:46 CEST 2010
On Fri, 17 Sep 2010 13:00:08 -0700
<raymond.hettinger at gmail.com> wrote:
> One of the use cases for named tuples is to have them be automatically created from a SQL
> query or CSV header. Sometimes (but not often), those can have a huge number of columns. In
> Python 2.x, it worked just fine -- we had a test for a named tuple with 5000 fields. In
> Python 3.x, there is a SyntaxError when there are more than 255 fields.
I don't understand your explanation. You can't pass a namedtuple using
the **kw convention:
>>> import collections
>>> T = collections.namedtuple('a', 'b c d')
>>> t = T(1,2,3)
>>> def f(**a): pass
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: f() argument after ** must be a mapping, not a
Besides, even if that worked, you are doing an intermediate conversion
to a dict, which is wasteful. Why not simply pass the namedtuple as a
> The bad news is that an implementation detail has become visible and added a language
> restriction. The 255 limit seems weird to me in a version of Python that has gone to lengths
> to unify ints and longs so that char/short/long boundaries stop manifesting themselves to users.
Well, it sounds like a theoretical worry of no practical value to me.
The **kw notation is meant to marshal passing of actual keyword args,
which are going to be explicitly typed in either at the call site or at
the function definition site (ignoring any proxies in-between). Nobody
is going to type more than 255 keyword arguments by hand. And there's
generated code, but since it's generated they can easily find a
> If the new restriction isn't necessary, it would be great to remove it.
I assume the restriction is useful since, according to your explanation,
it improves the encoding of opcodes.
Of course, we could switch bytecode to use a standard 32-bit word
size, but someone has to propose a patch.
More information about the Python-ideas