Steve Holden writes: > I do feel that for Python 3 it might be better to make a clean > separation between keywords and positionals: in other words, of the > function definition specifies a keyword argument then a keyword must be > used to present it. > > This would allow users to provide an arbitrary number of positionals > rather than having them become keyword arguments. At present it's > difficult to specify that.
Antoine Pitrou already responded: > Do you mean it would also be forbidden to invoke a "positional" argument > using its keyword? It would be a huge step back in usability IMO. Some > people like invoking by position (because it's shorter) and some others > prefer invoking by keyword (because it's more explicit). Why should the > implementer of the API have to make a choice for the user of the API ? I strongly agree with Antoine here, but the combination of "keyword arguments after the star": > foo(a, b, c=1, *args, d=2, e=5, **kwargs) > ^^^^^^^^^ ^^^^^^^^ > positional only with kw > or with kw with "star without a name": > def f(a, b, c=default, *, foo=1, bar=2): pass > > Here, c is a positional argument with a default value, while foo and bar are > forced to be keyword arguments. is quite tempting. It satisfies Steve by allowing the implementer of the function to require keyword arguments. It satisfies Antoine and myself by also allowing the implementor of the function to permit positional OR keyword use, and making this the default behavior. It is logically consistant. There's just one big problem that I know of: Guido writes: > I've always wanted to write that as > > f(a, b, *args, foo=1, bar=2, **kwds) > > but the current grammar doesn't allow it. Hmm.... why doesn't the current grammar allow it, and can we fix that? I don't see that it's a limitation of the one-token-lookahead, could we permit this syntax by rearanging bits of the grammer? -- Michael Chermside _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
