On Sat, Dec 04, 2021 at 03:14:46PM +1100, Chris Angelico wrote:
> Lots and lots and lots of potential problems. Consider:
>
> def f():
> a = 1
> def f(b, x=>a+b):
> def g(): return x, a, b
>
> Both a and b are closure variables - one because it comes from an
> outer scope, one be
On Sat, Dec 4, 2021 at 8:48 PM Steven D'Aprano wrote:
>
> On Sat, Dec 04, 2021 at 03:14:46PM +1100, Chris Angelico wrote:
>
> > Lots and lots and lots of potential problems. Consider:
> >
> > def f():
> > a = 1
> > def f(b, x=>a+b):
> > def g(): return x, a, b
> >
> > Both a and b
> On 4 Dec 2021, at 09:44, Steven D'Aprano wrote:
>
> On Sat, Dec 04, 2021 at 03:14:46PM +1100, Chris Angelico wrote:
>
>> Lots and lots and lots of potential problems. Consider:
>>
>> def f():
>>a = 1
>>def f(b, x=>a+b):
>>def g(): return x, a, b
>>
>> Both a and b are clos
> On 1 Dec 2021, at 06:16, Chris Angelico wrote:
>
> I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/
> with some additional information about the reference implementation,
> and some clarifications elsewhere.
(I suspect that there was a reply that I should be replying to b
On 2021-12-04 03:50, Chris Angelico wrote:
On Sat, Dec 4, 2021 at 8:48 PM Steven D'Aprano wrote:
And third, when the interpreter fetches a default from
func.__defaults__, if it is a LB function, it automatically calls that
function with the parameters to the left of x (which in this case
would
On Sun, Dec 5, 2021 at 6:16 AM Brendan Barnwell wrote:
>
> On 2021-12-04 03:50, Chris Angelico wrote:
> > On Sat, Dec 4, 2021 at 8:48 PM Steven D'Aprano wrote:
> >> And third, when the interpreter fetches a default from
> >> func.__defaults__, if it is a LB function, it automatically calls that
>
On Sun, Dec 5, 2021 at 5:29 AM Barry Scott wrote:
>
>
>
> > On 1 Dec 2021, at 06:16, Chris Angelico wrote:
> >
> > I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/
> > with some additional information about the reference implementation,
> > and some clarifications elsewhere.
>
On Sat, Dec 04, 2021 at 10:50:14PM +1100, Chris Angelico wrote:
> > syntactic sugar for this:
> >
> > def f(b, x=lambda b: a+b): ...
> >
> > except that the lambda has the LB flag set.
>
> Okay. So the references to 'a' and 'b' here are one more level of
> function inside the actual function
On Sun, Dec 5, 2021 at 11:34 AM Steven D'Aprano wrote:
>
> On Sat, Dec 04, 2021 at 10:50:14PM +1100, Chris Angelico wrote:
>
> > > syntactic sugar for this:
> > >
> > > def f(b, x=lambda b: a+b): ...
> > >
> > > except that the lambda has the LB flag set.
> >
> > Okay. So the references to 'a'
Thank you for doing this research, Steven.
The designers of 12 languages have chosen to provide late binding; those
of 3 or 4 have provided early binding.
I think this is at least tenuous evidence in favour of my belief that
late binding is more useful than early binding.
Best wishes
Rob Cliffe
On Sun, Dec 5, 2021 at 2:14 PM Rob Cliffe via Python-ideas
wrote:
>
> Thank you for doing this research, Steven.
> The designers of 12 languages have chosen to provide late binding; those
> of 3 or 4 have provided early binding.
> I think this is at least tenuous evidence in favour of my belief th
On Sat, Dec 4, 2021, 10:14 PM Rob Cliffe via Python-ideas
> The designers of 12 languages have chosen to provide late binding; those
> of 3 or 4 have provided early binding.
> I think this is at least tenuous evidence in favour of my belief that late
> binding is more useful than early binding.
>
Barry Scott writes:
> There are many possible implementation of the late bound idea that
> could create an object/default expression.
> But is it reasonable to bother with that added
> complexity/maintenance burden for a first implementation.
Yes. If you don't do it, you'll have backward com
On Sun, Dec 5, 2021 at 3:03 PM David Mertz, Ph.D. wrote:
> Probably fewer than half of functions I've written use named parameters at
> all.
>
Not sure I'm understanding you correctly; in what way are named
parameters relevant here?
ChrisA
___
Python-
On Sun, Dec 5, 2021 at 3:08 PM Stephen J. Turnbull
wrote:
>
> Barry Scott writes:
>
> > There are many possible implementation of the late bound idea that
> > could create an object/default expression.
> > But is it reasonable to bother with that added
> > complexity/maintenance burden for a f
On Sat, Dec 4, 2021, 11:13 PM Chris Angelico
> Not sure I'm understanding you correctly; in what way are named parameters
> relevant here?
>
def add(a, b):
return a+b
How could you write that differently with your PEP (which only pertains to
named parameters, not positional)?
>
On Sun, Dec 5, 2021 at 3:17 PM David Mertz, Ph.D. wrote:
>
> On Sat, Dec 4, 2021, 11:13 PM Chris Angelico
>>
>> Not sure I'm understanding you correctly; in what way are named parameters
>> relevant here?
>
>
> def add(a, b):
> return a+b
>
> How could you write that differently with your PEP
On Sat, Dec 4, 2021 at 11:25 PM Chris Angelico wrote:
> > def add(a, b):
> > return a+b
> > How could you write that differently with your PEP
>
> I wouldn't. There are no default arguments, and nothing needs to be
> changed.
>
I do recognize that I *could* call that with named arguments. I
On Sun, Dec 5, 2021 at 3:39 PM David Mertz, Ph.D. wrote:
>
> On Sat, Dec 4, 2021 at 11:25 PM Chris Angelico wrote:
>>
>> > def add(a, b):
>> > return a+b
>> > How could you write that differently with your PEP
>>
>> I wouldn't. There are no default arguments, and nothing needs to be changed.
On 2021-12-01 at 17:16:34 +1100,
Chris Angelico wrote:
> *PEP 671: Syntax for late-bound function argument defaults*
>
> Questions, for you all:
>
> 1) If this feature existed in Python 3.11 exactly as described, would
> you use it?
No. I understand the arguments (pun intended) for the propos
Brendan Barnwell writes:
> The ability to write something in the function signature that we
> can already write in the body, and that quite naturally belongs in
> the body, because it is executed when the function is called, not
> when it is defined.
I'm basically in sympathy with your conclu
21 matches
Mail list logo
