On Sun, Oct 31, 2021 at 9:17 AM Brendan Barnwell <brenb...@brenbarn.net> wrote: > > On 2021-10-26 20:15, Chris Angelico wrote: > > One of my goals here is to ensure that the distinction between > > early-bound and late-bound argument defaults is, again, orthogonal > > with everything else. You should be able to change "x=None" to "x=>[]" > > without having to wonder whether you're stopping yourself from adding > > a type annotation in the future. This is why I'm strongly inclined to > > syntaxes that adorn the equals sign, rather than those which put > > tokens elsewhere (eg "@x=[]"), because it keeps the default part > > self-contained. > > Another point that I forgot to mention when replying to this before: > > You are phrasing this in terms of orthogonality in argument-passing. > But why think of it that way? If we think of it in terms of expression > evaluation, your proposal is quite non-orthogonal, because you're > essentially creating a very limited form of deferred evaluation that > works only in function arguments. In a function argument, people will > be able to do `x=>[]`, but they won't be able to do that anywhere else. > So you're creating a "mode" for deferred evaluation. > > This is why I don't get why you seem so resistant to the idea of a > more > general deferred evaluation approach to this problem. Generalizing > deferred evaluation somehow would make the proposal MORE orthogonal to > other features, because it would mean you could use a deferred > expression as an argument in the same way you could use it in other places. >
Please expand on this. How would you provide an expression that gets evaluated in *someone else's context*? The way I've built it, the expression is written and compiled in the context that it will run in. The code for the default expression is part of the function that it serves. If I were to generalize this in any way, it would be to separate two parts: "optional parameter, if omitted, leave unbound" and "if local is unbound: do something". Not to "here's an expression, go evaluate it later", which requires a lot more compiler help. 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/2V4LIN36AO2TBTSSI426JJDAY5K6QQBJ/ Code of Conduct: http://python.org/psf/codeofconduct/
