Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Remove namedtuple 255 arguments restriction #63096

Closed
valorien mannequin opened this issue Aug 31, 2013 · 8 comments
Closed

Remove namedtuple 255 arguments restriction #63096

valorien mannequin opened this issue Aug 31, 2013 · 8 comments
Assignees
@serhiy-storchaka
Labels
3.7 (EOL) end of life interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement

Comments

@valorien
Copy link
Mannequin

valorien mannequin commented Aug 31, 2013

BPO 18896
Nosy @rhettinger, @pitrou, @giampaolo, @bitdancer, @serhiy-storchaka
PRs
  • [Do Not Merge] Convert Misc/NEWS so that it is managed by towncrier #552
    		•
    Files
  • no-params-limit.patch
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/serhiy-storchaka'
closed_at = <Date 2016-12-16.17:22:24.533>
created_at = <Date 2013-08-31.18:05:10.642>
labels = ['interpreter-core', 'type-feature', '3.7']
title = 'Remove namedtuple 255 arguments restriction'
updated_at = <Date 2017-03-31.16:36:34.843>
user = 'https://bugs.python.org/valorien'

    bugs.python.org fields:

    activity = <Date 2017-03-31.16:36:34.843>
actor = 'dstufft'
assignee = 'serhiy.storchaka'
closed = True
closed_date = <Date 2016-12-16.17:22:24.533>
closer = 'serhiy.storchaka'
components = ['Interpreter Core']
creation = <Date 2013-08-31.18:05:10.642>
creator = 'valorien'
dependencies = []
files = ['45667']
hgrepos = []
issue_num = 18896
keywords = ['patch']
message_count = 8.0
messages = ['196660', '196664', '196667', '196704', '281854', '283242', '283419', '283420']
nosy_count = 7.0
nosy_names = ['rhettinger', 'pitrou', 'giampaolo.rodola', 'r.david.murray', 'python-dev', 'serhiy.storchaka', 'valorien']
pr_nums = ['552']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue18896'
versions = ['Python 3.7']
    @valorien
    Copy link
    Mannequin Author

    valorien mannequin commented Aug 31, 2013

    Named tuples offer a useful mix of features from both dict and tuple data structures. However, unlike dictionaries and tuples, Named tuples are only allowed to hold up to 255 items.

    This behavior seems inconsistent and un-Pythonic.
    Is there a way to remove this restriction? Why not set a much higher limit?

    Also see:
    http://grokbase.com/t/python/python-ideas/109hbv63sv/new-3-x-restriction-on-number-of-keyword-arguments#responses_tab_top

    http://stackoverflow.com/questions/18550270/any-way-to-bypass-namedtuple-255-arguments-limitation

    @valorien valorien mannequin added the type-feature A feature request or enhancement label Aug 31, 2013
    @pitrou
    Copy link
    Member

    pitrou commented Aug 31, 2013

    I'll let Raymond give his answer here, but namedtuples are meant as lightweight structures or records (if you know C, think "struct"), not arbitrary containers.

    @valorien
    Copy link
    Mannequin Author

    valorien mannequin commented Aug 31, 2013

    @pitrou:
    Thank you for your answer.
    I agree they should not replace databases or files, but I think 255 is just way too lightweight. It feels unnatural to have this limitation for no specific reason.

    Recently, I've seen a lot of solutions that emulate the namedtuple functionality with some classes in order to workaround this issue, but they all feel "forced" and require some unsavory hacks.

    I think namedtuple is one the most useful structures in the language, and like tuples and dicts, shouldn't be limited by design.

    @rhettinger
    Copy link
    Contributor

    I would like to see the limitation removed. IIRC, Guido has said the same.

    That said, the limitation isn't due to anything in the namedtuple code. Instead, it is due to a CPython bytecode implementation detail that limits all function/method definitions to no more than 255 arguments.

    @serhiy-storchaka
    Copy link
    Member

    Currently it is not possible to declare a Python function with more than 255 parameters. There were two historical causes of this:

    1. Opcodes MAKE_FUNCTION and MAKE_CLOSURE packed the number of default values for positional and keyword parameters in the opcode argument as 8-bit numbers.

    2. co_cell2arg was of type "unsigned char *". It's mapped a cell index to an argument index and didn't support arguments with index > 254.

    The first limitation is disappeared in 3.6 after changing the format of MAKE_FUNCTION (bpo-27095). Proposed patch gets rid of the second cause by changing the type of co_cell2arg and removes explicit check in the compiler.

    @serhiy-storchaka serhiy-storchaka added interpreter-core (Objects, Python, Grammar, and Parser dirs) 3.7 (EOL) end of life labels Nov 28, 2016
    @serhiy-storchaka serhiy-storchaka self-assigned this Dec 14, 2016
    @rhettinger
    Copy link
    Contributor

    Thanks. The patch looks good.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Dec 16, 2016

    New changeset 7454ca88aacb by Serhiy Storchaka in branch 'default':
    Issue bpo-18896: Python function can now have more than 255 parameters.
    https://hg.python.org/cpython/rev/7454ca88aacb

    @serhiy-storchaka
    Copy link
    Member

    Thank you Raymond for your review.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees

    @serhiy-storchaka serhiy-storchaka

    Labels
    3.7 (EOL) end of life interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    3 participants
    @rhettinger @pitrou @serhiy-storchaka