On Sun, Jun 19, 2022, 3:27 AM Chris Angelico
> > I'm still -1 because I don't think the purpose alone is close to worth
> the cost of new syntax... And especially not using sigils that are
> confusing to read in code.
> >
> > The topic of "late binding in function signatures" simply isn't
> *orthogonal* to "late binding in the general sense." Yes, they are
> distinct, but very closely adjacent.
>
> Every argument you've just made is ALSO an argument against function
> defaults in general. Do you think that they aren't worth syntax either?
>
I honestly can find no connection between what I've argued and "function
defaults in general." It feels like a non sequitur, but I accept that they
somehow connect in your mind.
Way back last Oct when this discussion had it's first round, someone
(probably Steven, but maybe it was someone else) did a survey of a numerous
programming languages, and whether they use early binding or late binding
of default function arguments.
The result was that MOST languages do late (call time) binding, albeit many
of those are compiled languages where early binding doesn't really make
sense. Some, like JavaScript don't have defaults at all, so the approach is
actually similar to Python:
const myfunc = (a, b, c) => {
if (typeof c === 'undefined') { c = ... }
}
That's a sentinel, but worse than Python in several ways. Others like Perl
don't really have named arguments at all, but that weird implicit list you
can pop from.
The one thing that there were ZERO examples of elsewhere was what you
propose: slightly different syntax to allow both early-bound and
late-bound. Admittedly, if Python had done late-bound from 1.0, probably no
one would now have a PEP to add an early-bound spelling variant.
If Python had always been late-bound, I'm sure I'd be perfectly happy with
it today. But sentinels are really easy, and obscure sigils are really
hard. So adding the new spelling just makes Python worse. Beginners have
something needless to learn, and experienced developers have just a little
more cognitive burden all the time.
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/4TMLNYHBLQEY3TBWLH3S3DEDCFWN2Q2M/
Code of Conduct: http://python.org/psf/codeofconduct/
