[Python-Dev] PEP 457: Syntax For Positional-Only Parameters
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