[issue38560] Allow iterable argument unpacking after a keyword argument?

[Brandt Bucher]

Brandt Bucher  added the comment:

I've found one occurrence of this in the CPython codebase, in test_ast.py. 
Basically it makes sure that the following expression parses and compiles 
correctly:

f(1,2,c=3,*d,**e)

I doubt that this is to protect against regressions in this specific syntax. 
More likely it's just trying to create as many of the different argument 
passing AST nodes as possible in one call (it's the only test for function 
calls with arguments). It can probably be slightly refactored:

f(1,2,*c,d=3,**e)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38560] Allow iterable argument unpacking after a keyword argument?

[Josh Rosenberg]

Josh Rosenberg  added the comment:

I'd be +1 on this, but I'm worried about existing code relying on the 
functional use case from your example.

If we are going to discourage it, I think we either have to:

1. Have DeprecationWarning that turns into a SyntaxError, or
2. Never truly remove it, but make it a SyntaxWarning immediately and leave it 
that way indefinitely

--
nosy: +josh.r

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38560] Allow iterable argument unpacking after a keyword argument?

[Brandt Bucher]

New submission from Brandt Bucher :

Calls of the form f(name=value, *args) are currently legal syntax. The 
resulting argument binding is awkward, and almost never does what you 
want/expect it to:

>>> def f(x, y, z):
... print(x, y, z)
... 

>>> f(x=0, *(1, 2))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: f() got multiple values for argument 'x'

>>> f(y=0, *(1, 2))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: f() got multiple values for argument 'y'

>>> f(z=0, *(1, 2))
1 2 0

I'm not sure if this is intentional, or an oversight. Every other way of 
passing positional arguments after keyword arguments results in an error:

f(kwarg=kwarg, arg)  # SyntaxError: positional argument follows keyword argument
f(**kwargs, arg) # SyntaxError: positional argument follows keyword 
argument unpacking
f(**kwargs, *args)   # SyntaxError: iterable argument unpacking follows keyword 
argument unpacking

I think this case should raise a "SyntaxError: iterable argument unpacking 
follows keyword argument".

I'd like to work on this if we believe it should be changed.

--
components: Interpreter Core
messages: 355195
nosy: brandtbucher
priority: normal
severity: normal
status: open
title: Allow iterable argument unpacking after a keyword argument?
type: behavior
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com