Guido van Rossum wrote:

Personally, when I really wanted this, I've given the arguments names like __foo.

But that doesn't address all the reasons for wanting keyword-only args. An important reason is when you want to accept an arbitrary number of positional args, plus some keyword args. You can only do that now by manually unpacking things from **kwds. -- Greg

I wrote:

Guido van Rossum wrote:

...

Personally, when I really wanted this, I've given the arguments names like __foo.

But that doesn't address all the reasons for wanting keyword-only args.

Sorry, I got mixed up between the positional-only and keyword-only threads going on at the same time. Please disregard that comment. Personally I don't care much about positional-only args other than through *args. If an elegant way of accommodating them can be found, that's fine, but I wouldn't go out of my way to find one. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | greg.ewing@canterbury.ac.nz +--------------------------------------+

On Thursday 17 May 2007, George Sakkis wrote:

single "delimiter" symbol (e.g. '%') between pos-only and pos-or-kw would kill both birds with one stone, i.e. something like:

A delimeter that would be needed anyway would make this a little nicer: def myfunc(a, b, c=24; *, kw=42): pass This example would have 3 positional-only arguments (a, b, c) and one keyword-only argument (kw). Replacing the comma with a semicolon avoids the need for a syntax-only position (good, IMO), avoids introducing a new special character, and re-uses one that's rarely used anyway. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>

Ron Adam wrote:

Fred L. Drake, Jr. wrote:

...

On Thursday 17 May 2007, George Sakkis wrote:

...

single "delimiter" symbol (e.g. '%') between pos-only and pos-or-kw would kill both birds with one stone, i.e. something like:

A delimeter that would be needed anyway would make this a little nicer:

def myfunc(a, b, c=24; *, kw=42): pass

This example would have 3 positional-only arguments (a, b, c) and one keyword-only argument (kw).

Replacing the comma with a semicolon avoids the need for a syntax-only position (good, IMO), avoids introducing a new special character, and re-uses one that's rarely used anyway.

[A few thoughts]

def foo([positonal_only_args][; [kwd_args][; kwds_only]]): ...

def myfunct(a, b, c=42; e=99; kw=42): ...

Hmmm, this has a problem if you use * or ** in the definition. :( def myfunc(*args; ? ; **kwds): ... I think this would be an issue with some of the other ideas as well.

args = (1, 2, 3, 4) # 'e' can be in either args or kwds, kwds = {'kw': 42} # but not both.

bar = foo(*args, **kwds)

How about signature objects that are similar to slice objects?

sig = signature(*args, **kwds) # Pre package signature. sig = signature(1, 2, 3, 4, kw=42)

Could something like this have performance benefit if the same exact signature is used over and over? Possibly just passing a pre parsed name space to the function?

bar = foo(sig) # No need to unpack with * or **.

bar = foo(@sig) # Be lenient, extra args and kwds # are consumed or ignored. # But always error if something is missing.

The '@' sign is like a vortex which sucks up unused args. ;-)

Ron

On 5/16/07, George Sakkis wrote:

I see the utility of positional-only arguments, not just for the sake of symmetry but for pragmatic reasons; in fact the same reasons that serve as rationale to the keywords-only PEP.

uhh... could you spell those out, please? keywords-only is justified by functions that take both *args and a keyword that meets meets at least one of (1) Wasn't there before, so you can't stick it in front for backwards-compatibility reasons. (think "cmp") (2) Doesn't have a default (3) Should always be called by name, for readability. The following signature is awful def max(cmp=mysort, *args): And if you've already released max, it isn't even legal. How could there ever be an argument that *needs* to be positional? There are some that don't work if you call them by keyword, because they happen to be implemented in C without keyword support, but ... is there any reason to postively forbid using the argument name? The closest I can come to an example is def lappend(object): # This mimics list.append, and the *real* function wouldn't # take a keyword, so neither will I, just to prevent bad habits. Even that can already be written if you really want to... def lappend(*object): if len(object) != 1: raise TypeError("lappend takes ...") object = object[0] ... -jJ

On 5/18/07, Steven Bethard wrote:

On 5/18/07, Jim Jewett wrote:

...

How could there ever be an argument that *needs* to be positional?

As I've mentioned before, a great example of this is the dict() signature. It takes an optional "container" argument, followed by arbitrary keywords. If you write this in the naive way::

def __init__(self, container=None, **kwargs) ... for key, value in kwargs.items(): self[key] = value

then you get TypeErrors for the following code::

d.update(sequence=1, container=2) d.update(other=1, self=2)

Sorry, those should have been dict(sequence=1, container=2) dict(other=1, self=2) Of course, the same argument is valid for dict.update().

That is, the **kwargs can never include anything named 'self' or 'container'. If you could declare these two arguments as positional-only, you'd never run into this problem.

STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

On 5/18/07, Steven Bethard wrote:

On 5/16/07, George Sakkis wrote:

...

I see the utility of positional-only arguments, not just for the sake of symmetry but for pragmatic reasons; in fact the same reasons that serve as rationale to the keywords-only PEP.

In the hopes of keeping this discussion enough on track that we can eventually come to a conclusion, I thought I'd just take a couple minutes to summarize the proposals so far. I'm looking at the following function as an example::

def f(a, b=None, *, c=42, **kwargs)

where ``a`` and ``b`` should be positional-only and ``c`` should be keyword-only. Here are the alternatives I've seen so far:

* Use ** for keyword-only and * for positional-only: def (a, b=None, *, **, c=42, **kwargs): Pro: backwards compatible, reuses existing meanings Con: requires new syntax, changes keyword-only PEP -- Adam Olsen, aka Rhamphoryncus

On 5/20/07, Steven Bethard wrote:

So to write the dict() or dict.update() signatures, we'd write::

def update(*, self, container=None, **kwargs)

And to write the signature from my example, we'd write::

def f(*, a, b=None, **, c=42, **kwargs)

My only use cases are for functions with '*' at the beginning, because the only time I care about having positional only arguments is when I also have a **kwargs, and in that situation, I want *all* other arguments to be positional only.

Does anyone have a use case that requires both positional-only and positional-or-keyword arguments?

I don't have a hard use case, but more of a good API design argument, similar to those used to support the second subproposal of PEP 3102 (e.g. see [1]). Maybe it's just me but I often cannot find a good name for a parameter (at least not when I first write it) or I think of a more appropriate name later. I'd like to be able to go back and change it, knowing it won't break anything as it is always passed positionally. IOW, it's a way to say "these names are not part of the function's signature" and enforce this rather than just document it. For instance, think of a function that initially was designed to work for sequences and was defined as "def f(sequence, **kwds)". Later the implementor realizes that the same function works (or its implementation can easily change so that it works) for arbitrary iterables. It would be nice to go back and change the signature to "def f(iterable, **kwds)", knowing that nobody is calling it as f(sequence=range(10)). George [1] http://mail.python.org/pipermail/python-dev/2006-May/064695.html -- "If I have been able to see further, it was only because I stood on the shoulders of million monkeys."

On 5/20/07, Steven Bethard wrote:

On 5/20/07, George Sakkis wrote:

...

On 5/20/07, Steven Bethard wrote:

...

So to write the dict() or dict.update() signatures, we'd write::

def update(*, self, container=None, **kwargs)

And to write the signature from my example, we'd write::

def f(*, a, b=None, **, c=42, **kwargs)

My only use cases are for functions with '*' at the beginning, because the only time I care about having positional only arguments is when I also have a **kwargs, and in that situation, I want *all* other arguments to be positional only.

Does anyone have a use case that requires both positional-only and positional-or-keyword arguments? [snip] For instance, think of a function that initially was designed to work for sequences and was defined as "def f(sequence, **kwds)". Later the implementor realizes that the same function works (or its implementation can easily change so that it works) for arbitrary iterables. It would be nice to go back and change the signature to "def f(iterable, **kwds)", knowing that nobody is calling it as f(sequence=range(10)).

This is a good example for why you might want positional-only arguments. But I guess I wasn't clear -- I'm looking for an example where you need both a positional-only argument and a positional-or-keyword argument *in the same signature*.

The reason I ask is that I'd like to propose that the lone * can only appear at the beginning of the signature. That would cover the dict() and dict.update() use cases as well as your use case above::

def f(*, sequence, **kwds)

Are there any use cases that it wouldn't cover? Seems like the cautious programmer from your example above would want all of his positional arguments to be positional-only.

Are you proposing the removal of positional-or-keyword arguments altogether or only in the presence of positional-only ? In the former case, perhaps this needs a separate thread on its own as it's too big of a change. In the latter case, whatever reasons one has for using positional-or-keyword arguments, chances are that they will hold also in the presence of positional-only. Honestly, I can't think of a compelling reason for positional-or-keyword arguments (with or without the presence of positional-only in the same signature) other than that by definition offer two ways to the caller to spell the same thing. Even that could be considered a misfeature since it goes against TOOWTDI. In any case, that's more of a language design and philosophy argument ("should the caller of a function have the freedom on how to pass the arguments or that should be decided only by the function writer ?") rather than a hard use case. George -- "If I have been able to see further, it was only because I stood on the shoulders of million monkeys."

On 5/20/07, Steven Bethard wrote:

On 5/20/07, George Sakkis wrote:

...

Are you proposing the removal of positional-or-keyword arguments

No. My current proposal is:

- Everything after a * is a positional-only argument, up to the first ** - Everything after a ** is a keyword-only argument - A lone * may only appear at the beginning of the signature

In essence, this is changing the lone * of `PEP 3102`_ into a lone **, and allowing a lone * at the beginning of the signature to indicate that all positional arguments are positional-only.

.. _PEP 3102: http://www.python.org/dev/peps/pep-3102/

That means that in the following signature::

def f(*, a, b=None, *args, **, c=42, **kwargs)

- 'a' and 'b' are positional-only - 'args' is positional-only (as usual) - 'c' is keyword-only - 'kwargs' is keyword-only (as usual)

If you want positional-or-keyword arguments, simply omit the initial *::

def f(a, b=None, *args, **, c=42, **kwargs)

** is redundant here. You get the same behaviour without it: def f(a, b=None, *args, c=42, **kwargs) See below though.

- 'a' and 'b' are positional-or-keyword (as usual) - 'args' is positional-only (as usual) - 'c' is keyword-only - 'kwargs' is keyword-only (as usual)

If you want keyword-only arguments with no *args, simply omit it::

def f(a, b=None, **, c=42, **kwargs)

- 'a' and 'b' are positional-or-keyword (as usual) - 'c' is keyword-only - 'kwargs' is keyword-only (as usual)

Does anyone have use cases that this doesn't cover?

I initially had the same reservations you do about my proposal, but now I think there's a bigger problem: it undermines the obviousness of PEP 3102's behaviour. Consider this example: def compare(a, b, *args, key=None): Although not legal today, the behaviour is obvious. All positional arguments get sucked up in *args so key *must* be keyword-only. That leads to this variant: def compare(a, b, *, key=None): You continue sucking up extra positional args, but since it's nameless there must be none of them. Again, obvious. Changing the token required from * to ** or giving * extra behaviour when nameless just isn't obvious. Most of the proposed syntax changes also have a question of whether or not to include *args: "def f(a, *, *args)" or "def(a, *args, *)"? "def f((a), *args)" or "def f((a, *args))"? "def f(__a, *args)" or "def(__a, *__args)"? Finally (I hope) is the problem of motivation. Where as PEP 3102 is motivated by "explicit is better than implicit", positional-only arguments actually *want* implicit! It seems to be more for completeness and "C functions already support it". -1 on any syntax changes. A decorator may be okay, but I'm unsure the use cases are significant enough to warrant adding it. Go figure. -- Adam Olsen, aka Rhamphoryncus

Steven Bethard wrote:

I don't think the PEP 3102 meaning for lone * is any more intuitive than the meaning I'm proposing here.

Although I wouldn't go so far as to call the PEP 3102 behaviour "obvious", it is a fairly *logical* extension of the existing semantics. On the other hand, a rule like "arguments after a lone * are positional-only" is something new and arbitrary. It doesn't follow logically from anything existing. Also, your proposal assigns two quite different meanings to *. If it's followed by a name, it sucks up all remaining positional args, but if it's not, it can't suck up anything, since it's followed by more positional args! -- Greg

Steven Bethard wrote:

On 5/21/07, Adam Olsen wrote:

...

On 5/20/07, Steven Bethard wrote:

...

No. My current proposal is:

- Everything after a * is a positional-only argument, up to the first ** - Everything after a ** is a keyword-only argument - A lone * may only appear at the beginning of the signature

In essence, this is changing the lone * of `PEP 3102`_ into a lone **, and allowing a lone * at the beginning of the signature to indicate that all positional arguments are positional-only.

.. _PEP 3102: http://www.python.org/dev/peps/pep-3102/

That means that in the following signature::

def f(*, a, b=None, *args, **, c=42, **kwargs)

- 'a' and 'b' are positional-only - 'args' is positional-only (as usual) - 'c' is keyword-only - 'kwargs' is keyword-only (as usual)

If you want positional-or-keyword arguments, simply omit the initial *::

def f(a, b=None, *args, **, c=42, **kwargs) ** is redundant here. You get the same behaviour without it:

def f(a, b=None, *args, c=42, **kwargs)

See below though.

I note that below you argue for explicit is better than implicit. Requiring the ** even when it could be inferred from the *args is a good example of EIBTI. I don't have strong feelings on this issue though.

...

I initially had the same reservations you do about my proposal, but now I think there's a bigger problem: it undermines the obviousness of PEP 3102's behaviour. [snip] def compare(a, b, *, key=None):

You continue sucking up extra positional args, but since it's nameless there must be none of them. Again, obvious.

I have to disagree. The first thing I think when I see a lone * is multiplication, not "keyword-only arguments start after me". I would say it's just as obvious to see::

def g(*, a, b)

and say, "oh, it's after a * so it must be positional-only just like *args is". That is, I don't think the PEP 3102 meaning for lone * is any more intuitive than the meaning I'm proposing here.

I agree with Greg, it seems arbitrary. The number of meanings for the '*' is also growing too large I think. * multiply * pack in function defs # but at call time. * pack in left hand expressions # left of '=' * unpack in function calls * positional only indicator in function defs ** power ** pack dictionary in functions defs ** unpack dictionary in function calls ** keyword only indicator in function defs I'm sure this will get confusing to new users. Yes, each one is clear by context, but there's a lot of subtle behaviors by context going on here. What I would like is for unpack to be '^' instead of '*', then you would have... Packing operations: * multiply * pack in function defs * pack in left hand expressions ** power ** pack dictionary in functions defs Unpacking operations: ^ unpack in function calls ^ unpack in right hand expressions (possible) ^ positional only in function defs (See why I think so below) ^^ unpack dictionary in function calls ^^ keyword only in function defs (also see below) I think these become much easier to parse visually and mentally, so it's more of a human interface issue than a computer parsing issue. When using the "name=value" form in function definitions, it can be a positional or keyword argument. So all you need is a way to say this is either one or the other. (Using * here to show similarity, introducing the '^' further down.) *(b=2, c=3) positional only args *args rest of args **(b=2, c=3) keywords only kwds **kwds rest of keywords def f(a, *(b=2, c=3), *args) # b and c are positional only def f(a, **(b=2, c=3), **kwds) # b and c are keyword only Now the problem with this is when it's use with the *() and **() form, it resembles unpacking behavior, but in the *args, and **kwds form, it's packing behavior. Normally you would have only packing in a function def and unpacking in a function call. Now if we use ^ for unpacking, and * for packing, it reduces the number of meanings for the '*' and fixes the context of positional and keyword only arguments. def f(a, ^(b=2, c=3), *rest): b and c are positional only here. def f(a, d=5, ^^(b=2, c=3), **rest_kwds): # b and c are keywords only here. I feel this code better expresses it's intent. Think of the ^() as unpack these as args, and **() as unpack these as keywords. If '^' is used outside of function defs like the '*', it can retain it's meaning. a, b, *c = 1, 2, 3, 4, 5 # pack remainder z = (x, y, z) a, b, c, d = (a, ^z) # unpack z There is the possibility of extending this for use in other ways as well. xlist = [[1, 2], [3, 4, 5], [6, 7, 8, 9]] alist = [^x for x in xlist] This would have list "extend" behavior instead of list "append" behavior. Ok, just some possible ideas of how to organize all this. Cheers, Ron

...

Where as PEP 3102 is motivated by "explicit is better than implicit", positional-only arguments actually *want* implicit!

I don't follow this logic. How is a positional-only argument more implicit? You still have to supply it on every function call. It's not like you can omit it. Or are you saying that using positional arguments instead of keyword arguments is implicit?

...

A decorator may be okay, but I'm unsure the use cases are significant enough to warrant adding it.

Just for reference, here are the current motivating use cases:

* User mapping types that need to match the dict() and dict.update() method signatures * Code where positional argument names might change, e.g. George's def f(sequence) which later becomes def f(iterable)

Particularly since user mappings are relatively common, I do think this issue deserves at least a decorator.

STeVe

What I would like is for unpack to be '^' instead of '*', then you would have...

My first reaction was negative -- but then I remembered that I was caught by this trap myself more than once, because of the asymmetry between pack and unpack, with * magically doing the normally-right thing. So now I wonder if I wouldn't like if after all, and I'm instead picking at the presentation, so you can make a stronger case. On 5/21/07, Ron Adam wrote:

Now if we use ^ for unpacking, and * for packing, it reduces the number of meanings for the '*' and fixes the context of positional and keyword only arguments.

def f(a, ^(b=2, c=3), *rest): b and c are positional only here.

I don't think there should ever be positional-only arguments *after* a keywordable argument. Perhaps # a is a mandatory positional argument # b is an optional positional argument # c can be passed as a keyword, or as the third positional argument def f(^a, ^b=2, c=3, *rest): Or were you suggesting a tuple of the positional-only arguments, like # a is a mandatory positional argument # b is an optional positional argument # c can be passed as a keyword, or as the third positional argument def f(^(a, b=2), c=3, *rest):

There is the possibility of extending this for use in other ways as well.

xlist = [[1, 2], [3, 4, 5], [6, 7, 8, 9]]

alist = [^x for x in xlist]

This would have list "extend" behavior instead of list "append" behavior.

So alist == [1, 2, 3, 4, 5, 6, 7, 8, 9]? -jJ

-----Original Message----- From: python-ideas-bounces@python.org [mailto:python-ideas- bounces@python.org] On Behalf Of Ron Adam

def f(; a, b=2, c=3;): No positional only, no keyword only

Do you prohibit defaults in type 1, the pos-only? Not necc. Does this look right?

...

...

def f( a=0; b=1 ): ... print a, b f() 0, 1

Also, does this look right?

...

...

def f( a=0; b ): ... print a, b File "<stdin>", line 1 SyntaxError: non-default argument follows default argument

Any more groups? So far I have pos-only, pos-or-kw, and kw-only. If not, a ascii character works fine to delimit, like * and **. Do we want to annotate each parameter individually? This could get out of hand. But decorators won't let you do @f( k ) def j( k ): ... where @f( 'k' ) def j( k ): ... gets unwieldy and could show promise. Cf. Steven's positional only arguments decorator.

Aaron Brady schrieb:

...

-----Original Message----- From: python-ideas-bounces@python.org [mailto:python-ideas- bounces@python.org] On Behalf Of Aaron Brady Sent: Tuesday, May 22, 2007 4:45 AM

...

-----Original Message----- From: python-ideas-bounces@python.org [mailto:python-ideas- bounces@python.org] On Behalf Of Ron Adam

def f(; a, b=2, c=3;): No positional only, no keyword only

@f( 'k' ) def j( k ): ...

gets unwieldy and could show promise. Cf. Steven's positional only arguments decorator.

Cf. PEP 3102 Talin http://www.python.org/dev/peps/pep-3102/ Cf. PEP 3107 Winder and Lownds http://www.python.org/dev/peps/pep-3107/ Cf. PEP 3117 Brandl http://www.python.org/dev/peps/pep-3117/

def f( @k, @j )

Half-way compromise to Brandl, only in declaration not in use, and always optional.

I'd prefer no compromises being made when it comes to PEP 3117. Georg

Aaron Brady wrote:

...

...

...

...

def f(*, a, b=None, *args, **, c=42, **kwargs)

def f( *args, **kwargs ): if len( args ) < 2: raise error if 'b' in kwargs: raise error if 'c' not in kwargs: raise error a, b, args = args[:2], args[2:] c = kwargs['c']

It's an approximation; use case to the contrary?

I'm not sure why else you would post this reply other than a lack of understanding. The whole point of this discussion is to avoid burying this information inside the function body and have a complete function signature. f(*args, **kwargs) is the least useful function signature possible in python. -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu

-----Original Message----- From: python-ideas-bounces@python.org [mailto:python-ideas- bounces@python.org] On Behalf Of Steven Bethard Sent: Monday, May 21, 2007 1:59 AM

I don't follow this logic. How is a positional-only argument more implicit? You still have to supply it on every function call. It's not like you can omit it.

Not sure about it. If it's required, there is already support for it. Only omit the default value.

Particularly since user mappings are relatively common, I do think this issue deserves at least a decorator.

+1

On 5/21/07, Adam Olsen wrote:

now I think there's a bigger problem: it undermines the obviousness of PEP 3102's behaviour.

Consider this example:

def compare(a, b, *args, key=None):

Although not legal today, the behaviour is obvious. All positional arguments get sucked up in *args so key *must* be keyword-only.

This may not be so obvious anymore now that we have extended iterable unpacking from `PEP 3132`_. Given an iterable unpacking like:: a, b, *c, d = iterable I may assume that names after a *args work just like names before one:: def f(a, b, *c, d) So in this case I'd assume that the 'd' is also positional, not keyword-only. Again, I'm not saying people can't learn the appropriate meaning, just that it's not inherently obvious. .. _PEP 3132: http://www.python.org/dev/peps/pep-3132/ STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

On 5/21/07, Greg Ewing wrote:

Steven Bethard wrote:

...

On 5/21/07, Adam Olsen wrote:

...

All positional arguments get sucked up in *args so key *must* be keyword-only.

This may not be so obvious anymore now that we have extended iterable unpacking from `PEP 3132`_. Given an iterable unpacking like::

a, b, *c, d = iterable

I'm not in favour of allowing a * which isn't at the end here, for various reasons, one of which is that it weakens the analogy with call signatures.

I wasn't either, but I believe the PEP has already been accepted and implemented. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

On 5/21/07, Greg Ewing wrote:

I think the desire for positional-only args would be addressed well enough using a naming convention. Even without further explanation, if I saw something like

def f(_a, _b, _c): ...

it would be pretty clear to me that the author intended the parameter names to be an implementation detail.

So what about the signature for dict() and dict.update() where you want to write:: def update(self, container=None, **kwargs) Note that I shouldn't want to write '__container' because it's not an implementation detail. It's a valid positional argument that my clients can use. But if I write 'container', then I'm limiting what they can send as **kwargs and I can't reproduce the dict behavior:: >>> d = {} >>> d.update(container=1) >>> d {'container': 1} STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy