RetroSearch Browse

Wed Oct 9 03:05:25 CEST 2013 · https://mail.python.org/pipermail/python-dev/2013-October/129271.html

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>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2013-October/129271.html below:

[Python-Dev] PEP 457: Syntax For Positional-Only Parameters