[Python-ideas] Re: PEP 671 review of default arguments evaluation in other languages

On Sun, Dec 05, 2021 at 05:31:58PM -0700, Finn Mason wrote: > Also, on a kind of side note, what would be a situation where early binding > is advantageous to late binding? I can't think of one off the top of my > head. If your language only has one, early binding is better. You can easily simul

[Python-ideas] Re: PEP 671 review of default arguments evaluation in other languages

Finn Mason writes: > Is its not being done before really a good argument against it? No, but that's not the whole of the argument being made. The implied argument is that having two different ways to evaluate defaults is complexity that arguably isn't needed: either because late binding is a YA

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

Rob Cliffe via Python-ideas writes: > Nobody has attempted (or at least completed) a PEP, never mind an > implementation, of a "generalized deferred object/type", in the last N > years or decades. Haskell anything. Ruby blocks. Closer to home, properties and closures. So I don't think the

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On Sun, Dec 05, 2021 at 11:09:47AM -0800, Christopher Barker wrote: > But beyond a certain level of complexity, it shouldn’t be in signature > anyway. And it can only be a single expression anyway. True. But in that case, this PEP doesn't help either. Despite what Chris might think, I like this

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On 06/12/2021 09:44, Stephen J. Turnbull wrote: Rob Cliffe via Python-ideas writes: > Nobody has attempted (or at least completed) a PEP, never mind an > implementation, of a "generalized deferred object/type", in the last N > years or decades. Haskell anything. Ruby blocks. Closer to

[Python-ideas] Re: PEP 671 review of default arguments evaluation in other languages

On 06/12/2021 08:45, Steven D'Aprano wrote: On Sun, Dec 05, 2021 at 05:31:58PM -0700, Finn Mason wrote: Also, on a kind of side note, what would be a situation where early binding is advantageous to late binding? I can't think of one off the top of my head. If your language only has one, ear

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On Sun, Dec 05, 2021 at 08:15:34AM +1100, Chris Angelico wrote: > There are no objects that will behave differently if used in this way. > EVERY object can be a function default argument. Steve's proposal has > some objects (functions with the LB flag set) actually behave > differently - they *wil

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On Mon, 6 Dec 2021 at 09:45, Stephen J. Turnbull wrote: > > Rob Cliffe via Python-ideas writes: > > > Nobody has attempted (or at least completed) a PEP, never mind an > > implementation, of a "generalized deferred object/type", in the last N > > years or decades. > > Haskell anything. Ruby bl

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On Mon, Dec 6, 2021 at 10:02 PM Steven D'Aprano wrote: > > You assert that it "belongs in the body", but only because Python > > currently doesn't allow it to be anywhere else. Other languages have > > this exact information in the function signature. > > This argument about where the evaluation o

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On Mon, Dec 6, 2021 at 10:04 PM Paul Moore wrote: > Here's a prototype implementation, and a demonstration of how it would > be used to implement late bound arguments. Please note, I understand > that the syntax here is horrible. That's exactly the point, this needs > language support to be non-ho

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On Mon, Dec 06, 2021 at 11:00:43AM +, Paul Moore wrote: > At one level, it's trivial. A deferred expression is `lambda: > expression`. Evaluating it is `deferred_expr()`. [...] > We can't have a PEP or an implementation until we know what we're > proposing/implementing. Indeed. I have been wo

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On Mon, Dec 06, 2021 at 10:20:23PM +1100, Chris Angelico wrote: > The reason I consider this to be an independent proposal, and NOT a > mechanism for late-bound defaults, is this problem: > > def f(lst, n=>len(lst)): > lst.append(1) > print(n) > > f([10, 20, 30]) > > A late-bound defaul

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On Mon, 6 Dec 2021 at 11:21, Chris Angelico wrote: > The reason I consider this to be an independent proposal, and NOT a > mechanism for late-bound defaults, is this problem: > > def f(lst, n=>len(lst)): > lst.append(1) > print(n) > > f([10, 20, 30]) > > A late-bound default should print

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On Mon, Dec 06, 2021 at 03:14:36AM +1100, Chris Angelico wrote: > Closures cannot be executed without a context. Consider: > > def f(x=lambda: (a:=[])): > if isinstance(x, FunctionType): x = x() > print(a) > > Here's the problem: The name 'a' should be in the context of f, Not in the co

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On Tue, Dec 07, 2021 at 12:53:39AM +1100, Steven D'Aprano wrote: > If we can't execute the expression without the context existing, we make > it exist. Details to follow in another post. Here is some handwavy pseudo-code for setting up the context prior to calling a function "func": code =

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On Mon, Dec 06, 2021 at 10:16:06PM +1100, Chris Angelico wrote: > > You (Chris) argue in favour of your PEP, where the bytecode of the > > default expression is inlined into the function's body, because you > > insist that it belongs in the body. You justify that claim by making > > spurious argum

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On Tue, Dec 7, 2021 at 1:28 AM Steven D'Aprano wrote: > > On Tue, Dec 07, 2021 at 12:53:39AM +1100, Steven D'Aprano wrote: > > > If we can't execute the expression without the context existing, we make > > it exist. Details to follow in another post. > > Here is some handwavy pseudo-code for setti

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On 2021-12-05 08:14, Chris Angelico wrote: Closures cannot be executed without a context. Consider: def f(x=lambda: (a:=[])): if isinstance(x, FunctionType): x = x() print(a) Here's the problem: The name 'a' should be in the context of f, but that context*does not exist* until f star

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On Tue, Dec 7, 2021 at 6:16 AM Brendan Barnwell wrote: > > On 2021-12-05 08:14, Chris Angelico wrote: > > Closures cannot be executed without a context. Consider: > > > > def f(x=lambda: (a:=[])): > > if isinstance(x, FunctionType): x = x() > > print(a) > > > > Here's the problem: The na

[Python-ideas] Re: PEP 671 review of default arguments evaluation in other languages

Has anyone done a survey of, say, the cpython library codebase to see what proportion of arguments lists would significantly benefit from this PEP given as a proportion of the total codebase? In all the Python I've ever written or seen, I can only thing of one example of a custom sentinel ever

[Python-ideas] Re: PEP 671 review of default arguments evaluation in other languages

> On 6 Dec 2021, at 00:31, Finn Mason wrote: > > On Sun, Dec 5, 2021, 12:11 PM Brendan Barnwell > wrote: > On 2021-12-04 20:01, David Mertz, Ph.D. wrote: > > > > There are perfectly good ways to "fake" either one if you only have the > > other. Probably more work

[Python-ideas] Re: PEP 671 review of default arguments evaluation in other languages

On Mon, Dec 06, 2021 at 10:33:43AM +0100, Piotr Duda wrote: > You can simply write > def func(arg=>FUNC_DEFAULT_VALUE): Doh! Of course you can! I knew that! :-( -- Steve ___ Python-ideas mailing list -- [email protected] To unsubscribe send an e

[Python-ideas] Re: PEP 671 review of default arguments evaluation in other languages

On Mon, Dec 06, 2021 at 10:17:06AM +, Rob Cliffe via Python-ideas wrote: > >If your language only has one, early binding is better. > > That's your opinion.  It's not mine.  Witness the Stack Overflow > questions asking why `def f(arg=[])` "doesn't work". Of course it works. It does *exactly

[Python-ideas] Re: PEP 671 review of default arguments evaluation in other languages

On Mon, Dec 06, 2021 at 11:57:11AM -0800, Neil Girdhar wrote: > Has anyone done a survey of, say, the cpython library codebase to see what > proportion of arguments lists would significantly benefit from this PEP > given as a proportion of the total codebase? In all the Python I've ever > writ

[Python-ideas] Re: PEP 671 review of default arguments evaluation in other languages

On Mon, Dec 06, 2021 at 09:25:23PM +, Barry Scott wrote: > You can shoot your self in the foot with early-binding with ease. > You have to try harder with late-binding :-) def func(arg, sessionid=>secrets.token_hex()): ... "Why does the default session ID change every time I call

[Python-ideas] Re: PEP 671 review of default arguments evaluation in other languages

On Monday, December 6, 2021 at 6:28:10 PM UTC-5 Steven D'Aprano wrote: > On Mon, Dec 06, 2021 at 11:57:11AM -0800, Neil Girdhar wrote: > > > Has anyone done a survey of, say, the cpython library codebase to see > what > > proportion of arguments lists would significantly benefit from this PEP

[Python-ideas] Re: PEP 671 review of default arguments evaluation in other languages

On 06/12/2021 23:13, Steven D'Aprano wrote: On Mon, Dec 06, 2021 at 10:17:06AM +, Rob Cliffe via Python-ideas wrote: If your language only has one, early binding is better. That's your opinion.  It's not mine.  Witness the Stack Overflow questions asking why `def f(arg=[])` "doesn't work