3 ms·

"More than 255 arguments can now be passed to a function, and a function can now have more than 255 parameters." There are human devs who needed this? Or is th

"More than 255 arguments can now be passed to a function, and a function can now have more than 255 parameters." There are human devs who needed this? Or is this a sign that AI bots are now involved in language design?

akx 9y ago
Could be useful for code autogeneration of some ilk.
orf 9y ago
Perhaps it could trigger if you do function(*iterable), with a huge iterable?
- drizze 9y ago
  I think *iterable would just pass one argument that's a list, not pass each argument individually
  - fiddlerwoaroof 9y ago
    >>> print([1,2,3]) [1,2,3] >>> print(*[1,2,3]) 1 2 3
    - aisofteng 9y ago
      That doesn't tell you anything about when the list is expanded.
  - dragonwriter 9y ago
    The asterisk at the call site (where it turns an iterable into multiple passed arguments) not the function definition site (where it collects otherwise unconsumed arguments into a single list.)
  - orf 9y ago
    There may be some optimization at the interpreter level, but it appears to Python that each element of 'iterable' is passed as an individual argument
- winterlight 9y ago
  Nope, that works just fine. >>> def f(*x): print(x[-1]) >>> f(range(300)) 299 And surprisingly, in python 2.7, I was able to define a function that takes more than 255 arguments. But perhaps this only worked because I cheated and used exec. >>> exec("def f(" + ",".join("f" + str(x) for x in range(300)) + "): print(f299)" >>> f(*range(300)) 299
  - qquark 9y ago
    Interestingly enough, the function def (the exec part) does not work in 3.6, as one could expect, but in 2.7 even though the function definition works, you can make the call fail by generating actual parameters: >>> exec("def f(" + ",".join("f" + str(x) for x in range(300)) + "): print(f299)") >>> f(*range(300)) 299 >>> exec("f(" + ", ".join(str(i) for i in range(300)) + ")") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<string>", line 1 SyntaxError: more than 255 arguments When reducing the number of parameters to be invalid for f, the following error is shown: >>> exec("f(" + ", ".join(str(i) for i in range(30)) + ")") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<string>", line 1, in <module> TypeError: f() takes exactly 300 arguments (30 given) Which seems a bit paradoxical - "You need 300 arguments" - "No, wait, actually, you can't have more than 255" ... ;) It looks like they either had changed the internals of python 3, making it fail at the definition as a side effect instead of when calling, or used the same underlying logic but purposely chose to issue the exception to potentially catch the problem earlier...
- Waterluvian 9y ago
  I believe args and *kwargs have special opcodes already.
twoodfin 9y ago
First thing that pops to mind is ORM for extremely column-wide tables, which are not unusual in some domains.
- userbinator 9y ago
  I'm not too familiar with Python but something like that would typically be handled by passing a pointer to a data structure containing the column data, and not each column itself (or does/did it have a 255-item limit on its other data structures too...?)
  - twoodfin 9y ago
    OK, but then you need to populate the data structure. You can do it with individual member assignments of course, but some quick Googling (I am not a Python expert either) suggests that the default row/object constructor for SQLAlchemy is an arg-per-field function.
cwyers 9y ago
Dear God why.
nerdponx 9y ago
On python-dev a few month ago, Guido agreed with you that this is an arbitrary limitation that should be removed at some point. In particular, he worried that programmatically generated code would tend to run into this limitation.[0] [0]: https://bugs.python.org/msg142998 https://bugs.python.org/msg142998
TCM 9y ago
They have issued tagged with the bug report and adding more arguments to named tuple and to general functions seems to be the issue. The motivation for some of these changes were due to automatic code generation. See https://bugs.python.org/issue18896 https://bugs.python.org/issue18896 and https://bugs.python.org/issue12844 https://bugs.python.org/issue12844 for more information. Also, Django 1.3 had issues with 255 arguments for named tuples. To my knowledge there are no "AI Bots" that are involved in language design. Code generation is possible. Also solver aided languages See https://emina.github.io/rosette/ https://emina.github.io/rosette/
sbergot 9y ago
Saw one of those in a vb.net shop. It went that way: - someone creates a function to do something on a business concept that was not materialized by a class. Think of a bunch (~ 8) of properties that belong together but for some bad reason are moved in separate variables all over the place - another function has to work on a set of those objects. The dev who implements it thinks it would be a good idea to keep all parameters separate. No we have nproperties * nobjects parameters. The dev use a rigorous naming convention for readability (creatorFirstName, creatorLastName, validatorFirstName, etc) - now we have multiple sets (creatorFirstName1, 2, 3 ...) I don't remember the details but there was around three hundred parameters. edit: formatting
raymondh 9y ago
Guido had stated that he didn't want the implementation to place arbitrary limits on the language specification. This particular limit was not present in the early Python 2 releases. When the limit was added, limiting arguments wasn't the goal; instead, it was just an artifact of a patch regarding how keyword arguments and positional arguments we encoded in Python's bytecode scheme.

akx 9y ago

Could be useful for code autogeneration of some ilk.

orf 9y ago

Perhaps it could trigger if you do function(*iterable), with a huge iterable?

drizze 9y ago
I think *iterable would just pass one argument that's a list, not pass each argument individually
- fiddlerwoaroof 9y ago
  >>> print([1,2,3]) [1,2,3] >>> print(*[1,2,3]) 1 2 3
  - aisofteng 9y ago
    That doesn't tell you anything about when the list is expanded.
- dragonwriter 9y ago
  The asterisk at the call site (where it turns an iterable into multiple passed arguments) not the function definition site (where it collects otherwise unconsumed arguments into a single list.)
- orf 9y ago
  There may be some optimization at the interpreter level, but it appears to Python that each element of 'iterable' is passed as an individual argument
winterlight 9y ago
Nope, that works just fine. >>> def f(*x): print(x[-1]) >>> f(range(300)) 299 And surprisingly, in python 2.7, I was able to define a function that takes more than 255 arguments. But perhaps this only worked because I cheated and used exec. >>> exec("def f(" + ",".join("f" + str(x) for x in range(300)) + "): print(f299)" >>> f(*range(300)) 299
- qquark 9y ago
  Interestingly enough, the function def (the exec part) does not work in 3.6, as one could expect, but in 2.7 even though the function definition works, you can make the call fail by generating actual parameters: >>> exec("def f(" + ",".join("f" + str(x) for x in range(300)) + "): print(f299)") >>> f(*range(300)) 299 >>> exec("f(" + ", ".join(str(i) for i in range(300)) + ")") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<string>", line 1 SyntaxError: more than 255 arguments When reducing the number of parameters to be invalid for f, the following error is shown: >>> exec("f(" + ", ".join(str(i) for i in range(30)) + ")") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<string>", line 1, in <module> TypeError: f() takes exactly 300 arguments (30 given) Which seems a bit paradoxical - "You need 300 arguments" - "No, wait, actually, you can't have more than 255" ... ;) It looks like they either had changed the internals of python 3, making it fail at the definition as a side effect instead of when calling, or used the same underlying logic but purposely chose to issue the exception to potentially catch the problem earlier...
Waterluvian 9y ago
I believe args and *kwargs have special opcodes already.

twoodfin 9y ago

First thing that pops to mind is ORM for extremely column-wide tables, which are not unusual in some domains.

userbinator 9y ago
I'm not too familiar with Python but something like that would typically be handled by passing a pointer to a data structure containing the column data, and not each column itself (or does/did it have a 255-item limit on its other data structures too...?)
- twoodfin 9y ago
  OK, but then you need to populate the data structure. You can do it with individual member assignments of course, but some quick Googling (I am not a Python expert either) suggests that the default row/object constructor for SQLAlchemy is an arg-per-field function.

cwyers 9y ago

Dear God why.

nerdponx 9y ago

On python-dev a few month ago, Guido agreed with you that this is an arbitrary limitation that should be removed at some point. In particular, he worried that programmatically generated code would tend to run into this limitation.[0] [0]: https://bugs.python.org/msg142998 https://bugs.python.org/msg142998

TCM 9y ago

They have issued tagged with the bug report and adding more arguments to named tuple and to general functions seems to be the issue. The motivation for some of these changes were due to automatic code generation. See https://bugs.python.org/issue18896 https://bugs.python.org/issue18896 and https://bugs.python.org/issue12844 https://bugs.python.org/issue12844 for more information. Also, Django 1.3 had issues with 255 arguments for named tuples. To my knowledge there are no "AI Bots" that are involved in language design. Code generation is possible. Also solver aided languages See https://emina.github.io/rosette/ https://emina.github.io/rosette/

sbergot 9y ago

Saw one of those in a vb.net shop. It went that way: - someone creates a function to do something on a business concept that was not materialized by a class. Think of a bunch (~ 8) of properties that belong together but for some bad reason are moved in separate variables all over the place - another function has to work on a set of those objects. The dev who implements it thinks it would be a good idea to keep all parameters separate. No we have nproperties * nobjects parameters. The dev use a rigorous naming convention for readability (creatorFirstName, creatorLastName, validatorFirstName, etc) - now we have multiple sets (creatorFirstName1, 2, 3 ...) I don't remember the details but there was around three hundred parameters. edit: formatting

raymondh 9y ago

Guido had stated that he didn't want the implementation to place arbitrary limits on the language specification. This particular limit was not present in the early Python 2 releases. When the limit was added, limiting arguments wasn't the goal; instead, it was just an artifact of a patch regarding how keyword arguments and positional arguments we encoded in Python's bytecode scheme.