Re: Mutable defaults

2021-02-11 Thread J. Pic
Thank you, if anybody finds such an example in the wild where using a mutable default is actually better than a global or closure I would be happy to learn about it! About the proposal, this is a quick PoC of the @default decorator: import inspect def default(**defaults): def decorator(func

Re: Mutable defaults

2021-02-10 Thread Chris Angelico
On Thu, Feb 11, 2021 at 6:03 PM Ross Wilson wrote: > > On Thu, 11 Feb 2564 BE at 12:52 Grant Edwards > wrote: > > > On 2021-02-11, J. Pic wrote: > > > > > I just meant removing the whole "default value mutating" story, not > > > removing mutable variables. Really, I was wondering if there was a

Re: Mutable defaults

2021-02-10 Thread Ross Wilson
On Thu, 11 Feb 2564 BE at 12:52 Grant Edwards wrote: > On 2021-02-11, J. Pic wrote: > > > I just meant removing the whole "default value mutating" story, not > > removing mutable variables. Really, I was wondering if there was a use > case > > where this actually turns to an advantage, > > I've

Re: Mutable defaults

2021-02-10 Thread Grant Edwards
On 2021-02-11, J. Pic wrote: > I just meant removing the whole "default value mutating" story, not > removing mutable variables. Really, I was wondering if there was a use case > where this actually turns to an advantage, I've seen people show how it can be used to provide function-scope persist

Re: Mutable defaults

2021-02-10 Thread J. Pic
Ok, maybe: def foo(x=:[], y=:len(x)): As a shorthand for: @default(x=lambda: [], y=lambda x: len(x)) def foo(x=None, y=None): =: Is the contraction for =lambda: At the same time, this new syntax avoid breaking def foo(x=lamba: []) which is completely different as we know. Le jeu. 11 févr. 202

Re: Mutable defaults

2021-02-10 Thread Chris Angelico
On Thu, Feb 11, 2021 at 1:55 PM J. Pic wrote: > > Adding decorators with some inspect sauce could certainly work with the > syntax we already have: > > @default(x=lambda: copy([]), y=lambda x: len(x)) > def foo(x=None, y=None): This would work, although the copy is unnecessary here. But you're a

Re: Mutable defaults

2021-02-10 Thread J. Pic
Silly me, we don't even need copy but just execution @lazy(x=lambda: [], y=lamba x: len(x)) def foo(x=None, y=None): So only one operator is needed, the walrus is still fine: def foo(x:=[], y:=len(x)): Not copy, just evaluate. Le jeu. 11 févr. 2021 à 03:54, J. Pic a écrit : > Adding decorato

Re: Mutable defaults

2021-02-10 Thread J. Pic
Adding decorators with some inspect sauce could certainly work with the syntax we already have: @default(x=lambda: copy([]), y=lambda x: len(x)) def foo(x=None, y=None): I think this PoC is doable. But the lambda copy is a boring so, two decorators: @default.copy(x=[]) @default.call(y=lamba x: l

Re: Mutable defaults

2021-02-10 Thread Chris Angelico
On Thu, Feb 11, 2021 at 12:56 PM J. Pic wrote: > > I just meant removing the whole "default value mutating" story, not removing > mutable variables. Really, I was wondering if there was a use case where this > actually turns to an advantage, in which case it would be a designed feature > rather

Re: Mutable defaults

2021-02-10 Thread J. Pic
I just meant removing the whole "default value mutating" story, not removing mutable variables. Really, I was wondering if there was a use case where this actually turns to an advantage, in which case it would be a designed feature rather than an undesirable side effect, which it seems to be. Now

Re: Mutable defaults

2021-02-10 Thread Paul Bryan
Also -1 on changing the existing default behavior. +1 to an opt-in late-bound solution. On Thu, 2021-02-11 at 10:29 +1100, Chris Angelico wrote: > On Thu, Feb 11, 2021 at 10:17 AM J. Pic wrote: > > > > > Most of us know of the perils of mutable default values. > > > > And those who don't pay th

Re: Mutable defaults

2021-02-10 Thread Chris Angelico
On Thu, Feb 11, 2021 at 10:17 AM J. Pic wrote: > > > Most of us know of the perils of mutable default values. > > And those who don't pay the price. > > I wonder what would be the harm in removing them Define "removing". Most objects in Python are mutable; would that mean you can no longer use an

Re: Mutable defaults

2021-02-10 Thread J. Pic
> Most of us know of the perils of mutable default values. And those who don't pay the price. I wonder what would be the harm in removing them, or doing copy on call by default. -- https://mail.python.org/mailman/listinfo/python-list

Re: Mutable defaults

2021-02-09 Thread Terry Reedy
On 2/9/2021 10:17 AM, Antoon Pardon wrote: Most of us know of the perils of mutable default values. So I came up with the following proof of concept: Which is intended to do what? from inspect import signature as signature_of, Parameter from itertools import zip_longest from copy import copy

Re: Mutable defaults

2021-02-09 Thread Peter Otten
On 09/02/2021 16:17, Antoon Pardon wrote: Most of us know of the perils of mutable default values. So I came up with the following proof of concept: [...] def copy_defaults(f): Once you know you need that decorator you won't need it anymore ;) @copy_defaults def prepare(value, lst = []):

Re: Mutable defaults

2021-02-09 Thread Chris Angelico
On Wed, Feb 10, 2021 at 2:19 AM Antoon Pardon wrote: > > Most of us know of the perils of mutable default values. So I came up with > the following proof of concept: > > def copy_defaults(f): > > def wrapper(*args): > return f(*newargs) > return wrapper > > @copy_defaults > def