[Python-Dev] PEP 457: Syntax For Positional-Only Parameters (original) (raw)

Larry Hastings larry at hastings.org
Wed Oct 9 03:05:25 CEST 2013

A very quick reply, more tomorrow.

On 10/09/2013 02:15 AM, Steven D'Aprano wrote:

I note that in your example above, you put the comma outside the square bracket:

def addch([y, x,] ch, [attr], /): which seems perfectly readable to me.

It becomes less readable / more tiresome with nested groups. Which square bracket should the comma come after? Anyway, it seems like you agree with the syntactic requirement for other reasons.

(And, I already fixed the two places in the PEP where I had the comma outside the square brackets, thanks for pointing it out.)

I would much prefer Undefined and UndefinedType. That matches other singletons like None, NotImplemented, Ellipsis, even True and False.

You're probably right.

[Bikeshed: perhaps Missing is more appropriate than Undefined? After all, the parameter is defined, only the value is missing.]

Let the bikeshedding begin!

[Argument for allowing explicitly passing "undefined": this lets the iterable in foo(*iterable) yield "undefined", which could be convenient]

That's a good thought. But I'd be interested in more debate on the subject to see if people have other good reasons for/against encouraging explicitly using "undefined".

Because I think this is important, I'm going to raise it again: I think it is important for the PEP to justify why user functions cannot specify arbitrary values as defaults, not just Undefined.

Primarily because this codifies existing practice. C bulitins with positional-only decide how to assign their arguments based on how many there are, and when a parameter doesn't receive an argument it almost never gets a default value. I was trying to preserve these exact semantics, which is where the optional groups came from. And since I already had optional groups and "undefined", that seemed sufficient.

I'll also admit, I mainly ruled it out back before the prefer-left disambiguation rule, and allowing default values for positional-only led to loads of ambiguity. I hadn't reconsidered the restriction in light of the new rule.

But I still think the semantics get weird quickly. Consider:

def bar([a=7, b,] c, [d,] /):

Default values would have to grow from the outside in, staying away from the required positional-only parameter group. So on the left side they'd be backwards.

And if you call bar() with two arguments, you'd get (a b c), not (c d).
In fact there'd be no way of specifying d without providing four arguments. By that token there'd be no way of calling bar() and specifying d without stomping on the default value for a.

I agree I should do a better job of justifying the design in a future revision. I'd have to think long and hard before allowing default values for positional-only arguments... and that's a restriction I /wouldn't/ relax for Argument Clinic.

Anyway it's late, more tomorrow.

//arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20131009/d271a5fb/attachment.html>

More information about the Python-Dev mailing list