[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Mon, 26 Dec 2022 at 10:02, wrote: > > I didn't realize def foo(x, y=[]) had this strange artifact but it totally > makes sense, TIL. I did not get the right idea reading the PEP though, since > currently the motivation reads: > > > Optional function arguments, if omitted, often have some sort of logical > > default value. When this value depends on other arguments, or needs to be > > reevaluated each function call, there is currently no clean way to state > > this in the function header. > > and I kinda glossed over the second use-case. I feel like more emphasis can > be added since that part is what necessitates the new syntax. > > I do think that being able to reference other arguments is very useful in > it's own right and would go a long way in helping to solve the None check > problem brought up in PEP 505 even more cleanly. Yeah, they're both useful features, and both handled by the simple rule of "evaluate late-bound defaults in the context of the function body". 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/5A5UGJDLHW66VJXWUE4S6TSFLMFZIIDC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
I didn't realize def foo(x, y=[]) had this strange artifact but it totally makes sense, TIL. I did not get the right idea reading the PEP though, since currently the motivation reads: > Optional function arguments, if omitted, often have some sort of logical > default value. When this value depends on other arguments, or needs to be > reevaluated each function call, there is currently no clean way to state this > in the function header. and I kinda glossed over the second use-case. I feel like more emphasis can be added since that part is what necessitates the new syntax. I do think that being able to reference other arguments is very useful in it's own right and would go a long way in helping to solve the None check problem brought up in PEP 505 even more cleanly. ___ 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/D4DP4UB7LPYPBNPTXIZDRVD6NOPMGPQP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Mon, 26 Dec 2022 at 04:53, Steven D'Aprano wrote:
>
> On Sat, Dec 24, 2022 at 11:34:19AM -0500, Shironeko wrote:
> >
> > Is the => syntax needed? as far as I can think of, the only time where
> > late evaluation is needed is when the expression references the other
> > arguments.
>
> You are missing the most common case, the motivating case, for
> late-bound defaults: mutable defaults.
>
> def spam(x, y=>[]):
> pass
Exactly - this is the most important reason. So the true reason for
the => syntax is: in order to gain late-bound defaults, we have to
distinguish them from early-bound defaults (because changing ALL
function default arguments to late-bound would be a massive breaking
change). There's no particular reason for it to be "=>" specifically,
and other syntax options have been considered, but it does need to be
something other than "=".
> The ability for default values to refer to other parameters is a Nice To
> Have, not a Must Have. It has been a very long time since I have read
> the PEP, and I don't remember whether it reviews other languages to see
> what functionality they provide for defaults, but I don't think many
> other languages allow you to set the default of one parameter to be
> another parameter.
JavaScript does, by nature of its extremely simplistic definition of
argument defaults.
function f(x=1, y=x) {console.log("--> x = ", x, ", y = ", y);}
f(5)
--> x = 5 , y = 5
f()
--> x = 1 , y = 1
f(42, undefined)
--> x = 42 , y = 42
f(undefined, 123)
--> x = 1 , y = 123
Ruby does:
$ irb
irb(main):001:1* def f(x=1, y=x)
irb(main):002:1* puts "x = #{x}, y = #{y}"
irb(main):003:0> end
=> :f
irb(main):004:0> f()
x = 1, y = 1
=> nil
irb(main):005:0> f(123)
x = 123, y = 123
=> nil
I suspect that, in each case, the rule is quite simple: the argument
default is evaluated in the context of the function's body. Exactly
the same as PEP 671 proposes.
Any other languages to test?
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/CIPBJHCLGEUEVLOHPEA6WYNNCD63A7NP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Sat, Dec 24, 2022 at 11:34:19AM -0500, Shironeko wrote: > > Is the => syntax needed? as far as I can think of, the only time where > late evaluation is needed is when the expression references the other > arguments. You are missing the most common case, the motivating case, for late-bound defaults: mutable defaults. def spam(x, y=>[]): pass Here the intention is to have y's default be a *different* list each time you call spam(x), instead of the same list each time. The ability for default values to refer to other parameters is a Nice To Have, not a Must Have. It has been a very long time since I have read the PEP, and I don't remember whether it reviews other languages to see what functionality they provide for defaults, but I don't think many other languages allow you to set the default of one parameter to be another parameter. -- Steve ___ 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/HS7WJGA4CROKOCVVIECEXBNKEFOBQ3LQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
Is the => syntax needed? as far as I can think of, the only time where late evaluation is needed is when the expression references the other arguments. So the rule “if the expression reference other arguments it will get evaluated at function call time” should suffice right? In effect: def foo(a, b=len(a), c=max(b, d), d=15): gets translated into def foo(a, b=None, c=None, d=15): if b is None: b = len(a) if c is None: c = max(b, d) I’m not sure if this is already brought up in previous emails, I tried my best to search for it but can’t find any reference. Also, I think the sepc should not leave any ambiguous behavior otherwise it creates subtle incompatibilities when people use different implementations. This goes for whether all other argument can be referenced or only some argument can be. Or if the use of outer scope variables should get evaluated at def time, something like foo(a, b=max(a, outer.length())) should length() be ran once or on every function call. Stuff like these create an functional effect to the user so they ought to be well defined and not implementation specific. ___ 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/ENILUNXZUIAI4OOH6XLHLFYHXOAHO4JY/ Code of Conduct: http://python.org/psf/codeofconduct/
