[issue23316] Incorrect evaluation order of function arguments with *args

Irit Katriel added the comment: See also issue33492. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23316] Incorrect evaluation order of function arguments with *args

Terry J. Reedy added the comment: I was pointing out what to me is a second related contradiction in the doc, between one sentence and the next. -- ___ Python tracker ___

[issue23316] Incorrect evaluation order of function arguments with *args

Guido van Rossum added the comment: I'm currently not very interested in philosophizing about why we allow one syntax but not the other. -- ___ Python tracker ___

[issue23316] Incorrect evaluation order of function arguments with *args

Terry J. Reedy added the comment: (The nosy list change was an accident of my local copy not being complete refreshed before posting.) If (b=b, *c) were evaluated in order, then the byte code for b=b and any subsequent keyword arguments would have to be put aside, such as in a separate

[issue23316] Incorrect evaluation order of function arguments with *args

Guido van Rossum added the comment: Looks like Terry accidentally removed Serhiy. Adding him back. -- nosy: +Guido.van.Rossum, serhiy.storchaka ___ Python tracker ___

[issue23316] Incorrect evaluation order of function arguments with *args

Irit Katriel added the comment: It should be possible to make the compiler emit code that evaluates the arg values left to right in all cases. -- ___ Python tracker ___

[issue23316] Incorrect evaluation order of function arguments with *args

Change by Terry J. Reedy : -- nosy: -serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23316] Incorrect evaluation order of function arguments with *args

Change by Serhiy Storchaka : -- versions: +Python 3.11 -Python 3.4, Python 3.5 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue23316] Incorrect evaluation order of function arguments with *args

Serhiy Storchaka added the comment: Would not be be better in long term to get rid of irregularities? It would make the grammar simpler and the documentation clearer. The only use case of such syntax in wrappers, but they always can be rewritten in other style, with natural order of

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: FYI: https://github.com/PyCQA/pylint/issues/4586 -- ___ Python tracker ___ ___ Python-bugs-list

[issue23316] Incorrect evaluation order of function arguments with *args

Guido van Rossum added the comment: Well, it seems we're stuck -- we can't make the grammar more restrictive (at least, I don't think we should, since it is a backwards incompatibility), so we'll have to live with the exception. Since it is now clear what the rule is, we can update the

[issue23316] Incorrect evaluation order of function arguments with *args

Serhiy Storchaka added the comment: See also thread "Order of positional and keyword arguments" on the Python-Dev mailing list (https://mail.python.org/archives/list/python-...@python.org/thread/I6AUYV6DVEMP7XVYVDWC62N6PK6FHX3H/). -- nosy: +serhiy.storchaka

[issue23316] Incorrect evaluation order of function arguments with *args

Terry J. Reedy added the comment: The following does not consider keyword-only args with or without defaults. My understanding is the the compiler does not know or considered the signature of the function when evaluating the args. from dis import dis from itertools import permutations as

[issue23316] Incorrect evaluation order of function arguments with *args

Guido van Rossum added the comment: > "The one exception is in function calls with *expression after a keyword > argument: f(x=expr2, *expr1)." So the question before us is whether to add this phrase to the docs, or to tweak the compiler to fix it. It is certainly convenient to update the

[issue23316] Incorrect evaluation order of function arguments with *args

Terry J. Reedy added the comment: The particular example of left-to-right function evaluation in https://docs.python.org/3/reference/expressions.html#evaluation-order is "expr1(expr2, expr3, *expr4, **expr5)". Joshua's claim, without evidence, that "'f(*a(), b=b())' will evaluate b() before

[issue23316] Incorrect evaluation order of function arguments with *args

Irit Katriel added the comment: I don't think this is true anymore: >>> def a(): ... print('a') ... return (1,2) ... >>> def b(): ... print('b') ... return (3,4) ... >>> def f(*args, b=None): ... print('f') ... >>> f(*a(), b=b()) a b f >>> -- nosy: +iritkatriel

[issue23316] Incorrect evaluation order of function arguments with *args

Terry J. Reedy added the comment: I expect left to right as documented (and designed by Guido). His OK or clarification would be to intentionally do differently. -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: After thinking about this a bit more, my suggestion is not to fix it. Instead, I suggest that PEP 8 be modified to suggest that all positional arguments and iterable argument unpackings precede keyword arguments and keyword argument unpackings. Then, a tool

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: (I also suggest that the evaluation order within a function argument list to be defined to be positional and iterable before keyword, otherwise left-to-right —  rather than strictly left-to-right). -- ___ Python

[issue23316] Incorrect evaluation order of function arguments with *args

SilentGhost added the comment: It seems, if I read https://docs.python.org/3/reference/expressions.html#calls correctly that the evaluation order of the function arguments is not defined in general, as it depends on your use of keyword argument and exact function signature. Naturally, f(a(),

[issue23316] Incorrect evaluation order of function arguments with *args

R. David Murray added the comment: The resolution of issue 16967 argues that this should probably be considered a bug. It certainly goes against normal Python expectations. I think it should also be considered to be of low priority, though. -- nosy: +r.david.murray priority: normal

[issue23316] Incorrect evaluation order of function arguments with *args

New submission from Joshua Landau: It is claimed that all expressions are evaluated left-to-right, including in functions¹. However, f(*a(), b=b()) will evaluate b() before a(). ¹ https://docs.python.org/3/reference/expressions.html#evaluation-order -- components: Interpreter

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: actually, we accept alternation, so maybe a bit to say whether we start with a list or a dict followed by a length of the alternating sequence? -- ___ Python tracker rep...@bugs.python.org

[issue23316] Incorrect evaluation order of function arguments with *args

R. David Murray added the comment: Neil: I presume you are speaking of your in-progress PEP patch, and not the current python code? If so, please keep the discussion of handling this in the context of the PEP to the PEP issue. This issue should be for resolving the bug in the current code

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: Yes, sorry David. I got linked here from the other issue. In any case, in the current code, the longest alternating sequence possible is 4. So one way to solve this is to change the CALL_FUNCTION parameters to be lists and dicts only and then process the

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: another option is to add a LIST_EXTEND(stack_difference) opcode that would allow us to take the late iterable and extend a list at some arbitrary stack position. I had to add something like that for dicts for the other issue, so it would follow that pattern.

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: I assume this is the problem: dis.dis('f(*a(), b=b())') 1 0 LOAD_NAME0 (f) 3 LOAD_NAME1 (a) 6 CALL_FUNCTION0 (0 positional, 0 keyword pair) 9 LOAD_CONST