3 ms·

> This specific behaviour of python has always struck me as completely idiotic I'm curious, what would be your proposed solution? Make a special case exception

> This specific behaviour of python has always struck me as completely idiotic I'm curious, what would be your proposed solution? Make a special case exception for when the expression that constitutes a function default is evaluated? What would that exception look like?

neoncontrails 5y ago
Possibly something like this? (Code for illustration purposes only, of course -- please no one use this.) class AntiAntiPattern: 2 """A quick and dirty attempt to mock a Python class instance that 'undoes' the antipattern 3 described here: 4 https://docs.quantifiedcode.com/python-anti-patterns/correctness/mutable_default_value_as_argument.html)""" 5 __mutable_args__ = {} # TODO: a real implementation would probably use a WeakMap of some sort 6 def __init__(self, a, b=None, c={}, d=set()): 7 self.a = a 8 self.b = "foo" if b is None else b 9 self.c = c 10 self.d = "bar" if d is None else d 11 def __getattr__(self, k): 12 return self.__mutable_args__[k] if k in self.__mutable_args__ else super().getattr(k) 13 def __setattr__(self, k, v): 14 if v in self.__init__.__defaults__: 15 self.__mutable_args__[k] = v 16 else: 17 self.__dict__[k] = v 18 def __repr__(self): 19 return json.dumps(dict(self.__dict__, **self.__mutable_args__), default=str) >>> t = AntiAntiPattern(4, d = 'hello!') >>> t.__mutable_args__ {'b': None, 'c': {}} >>> t.__dict__ {'a': 4, 'd': 'hello!'} >>> t {"a": 4, "d": "hello!", "b": null, "c": {}} Edit: Oops, fixed a tiny logic bug in __init__. Trying to ween myself off of the 'a = a or "my_a_default"' syntax as instructed by previous commenters in this thread. :) Edit2: It dawned on me that this doesn't actually resolve the 'gotcha' unless `v` is replaced with `deepcopy(v)` on line 15; otherwise the same exact problem rears its head: >>> t = AntiAntiPattern(3, {}) >>> t.d set() >>> t.d.update([3,4]) >>> t {"a": 3, "b": {}, "c": {}, "d": "{3, 4}"} >>> t2 = AntiAntiPattern(4) >>> t2 {"a": 4, "b": {}, "c": {}, "d": "{3, 4}"} # aw, heck In which case I gather `__mutable_args__` is superfluous, and the solution involves simply making sure that class instances avoid pointing to the same memory objects?
- davidatbu 5y ago
  Thanks for this writeup. By "what is your proposed solution?" I meant to ask "how would you change the language semantics to remove this 'idiotic' footgun", not "how would you work around this footgun?" I apologize for the ambiguity. I initially thought this specific footgun was an unavoidable consequence in languages that primarily pass around references (like Python and Javascript). But it turns out that Javascript's default arguments do "make a special case exception for when the expression that constitutes a function default is evaluated!" https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Default_parameters#evaluated_at_call_time https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
bjoli 5y ago
My solution would be to fix it and break backwards compatibility: Any default value is evaluated anew on each function call without the specified value. Then you CAN mutate it to your hearts desire without impacting subsequent invocations. If you want to keep hidden mutable state between function invocations you should use a closure. def banana(parts = []): pass Calling that procedure without parts would mean parts would be bound to a NEW empty list, not the same old. Every new pyhton programmer is bitten by this sooner or later. Most people seem to think it is stupid, and relying on it seems, to me, to go against the python mantra of "being explicit", where explicit would mean either using an instance variable in the case of OO or a closure.
- davidatbu 5y ago
  Indeed, when I asked for potential solutions, I thought it would be ... weird, to evaluate default args at call time, but it turns out that many other languages are like that[0], and the wierdness was my subjective perception shaped by my Python-heavy background. Regarding breaking backward compatibility in a future release, I'm not qualified to weigh in on the design decision of balancing between the disadvantages of breaking backward compatibility and the advantage of more intuitive semantics. [0] https://github.com/microsoft/pyright/discussions/2306#discussioncomment-1337016 https://github.com/microsoft/pyright/discussions/2306#discus...
- patrickthebold 5y ago
  One useful case for the existing is to eagerly bind variables: Here's a stupid example. Notice in the first case printing i doesn't grab the value of i when the lambda is defined. The second case is likely what you want. >>> lambdas = [lambda : print(i) for i in range(2)] >>> for l in lambdas: ... l() ... 1 1 >>> lambdas = [lambda i=i: print(i) for i in range(2)] >>> for l in lambdas: ... l() ... 0 1
  - bjoli 5y ago
    Oh my, that's awful. Even in python there are better ways to close over a value :) I haven't written python in many years, but in the following example it is at least clear what is going on: def make_printer(n): def printer(): print(n) return printer [make_printer(i) for i in range(2)]

neoncontrails 5y ago

Possibly something like this? (Code for illustration purposes only, of course -- please no one use this.) class AntiAntiPattern: 2 """A quick and dirty attempt to mock a Python class instance that 'undoes' the antipattern 3 described here: 4 https://docs.quantifiedcode.com/python-anti-patterns/correctness/mutable_default_value_as_argument.html)""" 5 __mutable_args__ = {} # TODO: a real implementation would probably use a WeakMap of some sort 6 def __init__(self, a, b=None, c={}, d=set()): 7 self.a = a 8 self.b = "foo" if b is None else b 9 self.c = c 10 self.d = "bar" if d is None else d 11 def __getattr__(self, k): 12 return self.__mutable_args__[k] if k in self.__mutable_args__ else super().getattr(k) 13 def __setattr__(self, k, v): 14 if v in self.__init__.__defaults__: 15 self.__mutable_args__[k] = v 16 else: 17 self.__dict__[k] = v 18 def __repr__(self): 19 return json.dumps(dict(self.__dict__, **self.__mutable_args__), default=str) >>> t = AntiAntiPattern(4, d = 'hello!') >>> t.__mutable_args__ {'b': None, 'c': {}} >>> t.__dict__ {'a': 4, 'd': 'hello!'} >>> t {"a": 4, "d": "hello!", "b": null, "c": {}} Edit: Oops, fixed a tiny logic bug in __init__. Trying to ween myself off of the 'a = a or "my_a_default"' syntax as instructed by previous commenters in this thread. :) Edit2: It dawned on me that this doesn't actually resolve the 'gotcha' unless `v` is replaced with `deepcopy(v)` on line 15; otherwise the same exact problem rears its head: >>> t = AntiAntiPattern(3, {}) >>> t.d set() >>> t.d.update([3,4]) >>> t {"a": 3, "b": {}, "c": {}, "d": "{3, 4}"} >>> t2 = AntiAntiPattern(4) >>> t2 {"a": 4, "b": {}, "c": {}, "d": "{3, 4}"} # aw, heck In which case I gather `__mutable_args__` is superfluous, and the solution involves simply making sure that class instances avoid pointing to the same memory objects?

davidatbu 5y ago
Thanks for this writeup. By "what is your proposed solution?" I meant to ask "how would you change the language semantics to remove this 'idiotic' footgun", not "how would you work around this footgun?" I apologize for the ambiguity. I initially thought this specific footgun was an unavoidable consequence in languages that primarily pass around references (like Python and Javascript). But it turns out that Javascript's default arguments do "make a special case exception for when the expression that constitutes a function default is evaluated!" https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Default_parameters#evaluated_at_call_time https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

bjoli 5y ago

My solution would be to fix it and break backwards compatibility: Any default value is evaluated anew on each function call without the specified value. Then you CAN mutate it to your hearts desire without impacting subsequent invocations. If you want to keep hidden mutable state between function invocations you should use a closure. def banana(parts = []): pass Calling that procedure without parts would mean parts would be bound to a NEW empty list, not the same old. Every new pyhton programmer is bitten by this sooner or later. Most people seem to think it is stupid, and relying on it seems, to me, to go against the python mantra of "being explicit", where explicit would mean either using an instance variable in the case of OO or a closure.

davidatbu 5y ago
Indeed, when I asked for potential solutions, I thought it would be ... weird, to evaluate default args at call time, but it turns out that many other languages are like that[0], and the wierdness was my subjective perception shaped by my Python-heavy background. Regarding breaking backward compatibility in a future release, I'm not qualified to weigh in on the design decision of balancing between the disadvantages of breaking backward compatibility and the advantage of more intuitive semantics. [0] https://github.com/microsoft/pyright/discussions/2306#discussioncomment-1337016 https://github.com/microsoft/pyright/discussions/2306#discus...
patrickthebold 5y ago
One useful case for the existing is to eagerly bind variables: Here's a stupid example. Notice in the first case printing i doesn't grab the value of i when the lambda is defined. The second case is likely what you want. >>> lambdas = [lambda : print(i) for i in range(2)] >>> for l in lambdas: ... l() ... 1 1 >>> lambdas = [lambda i=i: print(i) for i in range(2)] >>> for l in lambdas: ... l() ... 0 1
- bjoli 5y ago
  Oh my, that's awful. Even in python there are better ways to close over a value :) I haven't written python in many years, but in the following example it is at least clear what is going on: def make_printer(n): def printer(): print(n) return printer [make_printer(i) for i in range(2)]