On Sun, Oct 24, 2021 at 7:58 AM Bruce Leban <br...@leban.us> wrote: > > On Sat, Oct 23, 2021 at 12:56 PM Guido van Rossum <gu...@python.org> wrote: >> >> I like that you're trying to fix this wart! I think that using a different >> syntax may be the only way out. My own bikeshed color to try would be `=>`, >> assuming we'll introduce `(x) => x+1` as the new lambda syntax, but I can >> see problems with both as well :-). >> > > +1 to this spelling. I started writing a message arguing that this should be > spelled with lambda because the fact that you're (effectively) writing a > function should be explicit (see below). But the syntax is ugly needing both > a lambda and a variant = operator. This solves that elegantly. >
Agreed; if it needs to remain self-contained, then yes, it would have to be a function, and there'd be good reason for making it look like one. As it is, it's more just "code that happens at the start of the function", but I think there's still value in using a syntax that people understand as a late binding system (as lambda functions will be). > On Sat, Oct 23, 2021 at 9:10 AM Chris Angelico <ros...@gmail.com> wrote: >> >> Proposal: Proper syntax and support for late-bound argument defaults. >> >> def bisect(a, x, lo=0, hi=:len(a)): >> if lo < 0: >> raise ValueError('lo must be non-negative') > > >> The syntax I've chosen is deliberately subtle, since - in many many >> cases - it won't make any difference whether the argument is early or >> late bound, so they should look similar. > > > I think a subtle difference in syntax is a bad idea since this is not a > subtle difference in behavior. If it makes no difference whether the argument > is early or late bound then you wouldn't be using it. > There IS a difference, but the difference should be subtle. Consider: x = 5 x = 5. These are deliberately similar, but they are quite definitely different, and they behave differently. (You can't use the second one to index a list, for instance.) Does the difference matter? Absolutely. Does the similarity matter? Yep. Similar things should look similar. The current front-runner syntax is: def bisect(a, x, lo=0, hi=>len(a)): This is only slightly less subtle. It's still a one-character difference which means that instead of being evaluated at definition time, it's evaluated at call time. This is deliberate; it should still look like (a) a parameter named "hi", (b) which is optional, and (c) which will default to the result of evaluating "len(a)". That's a good thing. > Here's one way you could imagine writing this today: > > def bisect(a, x, lo=0, hi=lambda: len(a)): > hi = hi() if callable(hi) else hi > ... > > which is clumsy and more importantly doesn't work because the binding of the > lambda occurs in the function definition context which doesn't have access to > the other parameters. > Right. It also doesn't solve the help() problem, since it's just going to show the (not-very-helpful) repr of a lambda function. It's not really much better than using object() as a sentinel, although it does at least avoid the global-pollution problem. It seems like there's broad interest in this, but a lot of details to nut out. I think it may be time for me to write up a full PEP. Guido, if I'm understanding recent SC decisions correctly, a PEP editor can self-sponsor, correct? ChrisA _______________________________________________ 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/2LHM6OSINJ7WF65AMDPVWPLLGMQG456J/ Code of Conduct: http://python.org/psf/codeofconduct/