Issue 37593: ast.arguments has confusing args/posonlyargs ordering

Positional-only arguments come before position-or-keyword arguments.

    def f(pos1, pos2, /, pos_or_kwd, *, kwd1, kwd2):

However, the posonlyargs are defined to come after args in the AST:

    arguments = (arg* args, arg* posonlyargs, arg? vararg, arg* kwonlyargs,
                 expr* kw_defaults, arg? kwarg, expr* defaults)

which results in confusing ast.dump output because they share defaults:

>>> r = ast.parse('lambda a=1,/,b=2:a+b', mode='eval')
>>> ast.dump(r.body.args)
"arguments(
    args=[arg(arg='b', annotation=None, type_comment=None)],
    posonlyargs=[arg(arg='a', annotation=None, type_comment=None)],
    vararg=None, kwonlyargs=[], kw_defaults=[], kwarg=None,
    defaults=[Constant(value=1, kind=None), Constant(value=2, kind=None)])"
[manually prettified]

Note how the ordering is 'args b', then 'posonlyargs a', but the defaults are still 1 then 2. This can be confusing to someone building an ast.arguments using keywords because the elements in 'defaults' have to be supplied in a specific order, but the keyword args 'args' and 'posonlyargs' do not, or to someone building an ast.arguments using positional arguments (because, maybe ironically, they're not keyword-only arguments) because 'posonlyargs' and 'args' must be supplied in a different order than the ordering of elements in 'defaults' would imply.

Potential solutions:
 1. Swap posonlyargs and args.
 2. Add a separate pos_defaults list.

New changeset cd6e83b4810549c308ab2d7315dbab526e35ccf6 by Miss Islington (bot) (Pablo Galindo) in branch 'master':
bpo-37593: Swap the positions of posonlyargs and args in the constructor of ast.parameters nodes (GH-14778)
https://github.com/python/cpython/commit/cd6e83b4810549c308ab2d7315dbab526e35ccf6

New changeset cf9a63c6c7e19f3d27cf3b5731d02cc216ef3dd1 by Miss Islington (bot) in branch '3.8':
bpo-37593: Swap the positions of posonlyargs and args in the constructor of ast.parameters nodes (GH-14778)
https://github.com/python/cpython/commit/cf9a63c6c7e19f3d27cf3b5731d02cc216ef3dd1

Thanks for the report, Benjamin!

The patch that was merged to fix this may have caused a regresion in xonsh.  Am working on a reproducer.

stage: patch review -> resolved