On 17Sep2010 21:23, MRAB email@example.com wrote: | On 17/09/2010 21:00, Raymond Hettinger 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. | > | >The origin of the change was a hack to fit positional argument counts | >and keyword-only argument counts in a single oparg in the python | >opcode encoding. [...] | >Is there any support here for trying to get smarter about the | >keyword-only argument implementation? [...] | | Strings can be any length, lists can be any length, even the humble int | can be any length! | It does seem unPythonic to have a low limit like that.
A big +10 from me. Implementation internals should not cause language level limitations.
If there's a (entirely reasonable IMHO) desire to get the opcode small, the count should be encoded in a compact be extendable form. (I speak here with no idea how inflexible the opcode readers are.)
As an example, I use a personal encoding for natural numbers scheme where values below 128 fit in one byte, 128 or more set the top bit on leading bytes to indicate followon bytes, so values up to 16383 fit in two bytes and so on arbitrarily. Compact and simple but unbounded.
Is something like that tractable for the Python opcodes?