On Fri, 17 Sep 2010 13:00:08 -0700 Raymond Hettinger email@example.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 regular parameter?
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 workaround anyway.
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.