On 8 July 2013 01:56, Jan Kaliszewski <zuo@chopin.edu.pl> wrote:
On 07.07.2013 01:03, Joshua Landau wrote:
Function calls may accept an unbound number of ``*`` and ``**`` unpackings. Arguments can now occur in any position in a function call. As usual, keyword arguments always go to their respective keys and positional arguments are then placed into the remaining positional slots. In approximate pseudo-notation::
function( argument or keyword_argument or *args or **kwargs, argument or keyword_argument or *args or **kwargs, ...
What do you exactly mean by "remaining positional slots"? Please note that the current behaviour is to raise TypeError when several (more than 1) arguments match the same parameter slot. IMHO it must be kept.
You're right -- I've never gotten that error before, so this is actually new to me. That is a nicer solution, and it keeps things clean.
Another question is related to this matter as well: if we adopt the idea of more than one **kwargs in function call -- what about key duplication? I.e. whether:
fun(**{'a': 1}, **{'a': 2})
...should raise TypeError as well, or should it be equivalent to fun(a=2)?
My first thought was that it should raise TypeError -- prohibition of parameter duplication is a simple and well settled rule for Python function calls. On second thought: it could be relaxed a bit if we agreed about another rule that would be simple enough, e.g.: "for anything *after* the first '**kwargs' (or maybe also bare '**,'?) another rule is applied: later arguments override earlier (looking from left to right), as in dict(...)/.update(...) or as in {**foo, **bar} in literals (if the rest of the PEP is accepted).
My first opinion would be that if relaxation is something people find useful, it would be suited to a separate proposal; it seems outside of this PEP's scope á mon avis. Given:
{1:"original", 1:"override"} {1: 'override'}
the most consistent behaviours would be what are in the PEP already, and I think that's worth keeping. --- Thinking about examples, the two cases ("status quo" rules [1] and relaxed rules [2]) would allow things like: def f(a, b, c=0, d=0, e=0): ... "Status Quo" rules: f(a, e=e, d=d, *[b, c]) Relaxed rules only: f(a, e=e, d=d, b, c) I brought up the idea for the Relaxed rules because the priority rules for arguments are somewhat complicated when you add in the ability to have multiple *args and **kwargs, and remove the restriction of *args after positionals and **kwargs after positionals. However, considering that the Relaxed rules are never actually useful AFAICT (there's no real reason to define positionals after keywords), this would be a simplification to the specification alone. That'll make it easier to learn the rules, I believe, but simply saying "write your arguments in a sane order" should do more than enough to cover it anyway. Personally, the rule from the issue itself (positionals, then keywords) is the simplest, but I agree with Guido that it's not worth breaking backwards compatibility. In a sense, then, the best way to describe the "Status Quo" as: Positionals, then Keywords -- but *if you must* you are allowed to put "*args" after keywords. I'm still undecided, so I'll leave this for others to comment on. An updated version of the PEP that removes the changes to function definitions and discusses the alternatives for function calls is attached. I haven't double-checked it, so it may be a bit rougher around the edges.