1

Default arguments of functions are initiated at function object creation time instead of function call time. This creates a trap for mutable default arguments where everybody at least once falls into. After that it only requires a bunch of boilerplate code in order to avert it. This behavior has only little upside to it.

The importance of the issue can be seen by this question or a simple google search.

So my question is why was this behavior not changed in one of the backwards-compability-breaking steps (1->2 or 2->3)? I'm sure that the core-dev team at least discussed this issue at some point. I was wondering if there is any info (mailing list, pep, ...) to read about the arguments why not to modify this behavior.

zondo
  • 19,901
  • 8
  • 44
  • 83
magu_
  • 4,766
  • 3
  • 45
  • 79
  • Because it wasn't. Because it was designed that way and nobody has seen sufficient need to back paddle on that design. – Not sure what kind of answer you expect here. – deceze Jun 12 '17 at 20:45
  • 1
    I guess there would be a non-trivial performance overhead if the function signature had to be evaluated every time the function is called, instead of just once at definition time. – Håken Lid Jun 12 '17 at 20:48
  • @HåkenLid. As stated I'm looking for some trace of discussions from the core-dev team. Ideally with their arguments for and against this behavior. – magu_ Jun 12 '17 at 20:51
  • The top answer in the linked question is by Alex Martelli. That's quite authoritative, I think. – Håken Lid Jun 12 '17 at 21:00
  • @HåkenLid. Yes that is correct. I'm wondering if this overhead still prohibiting in case of an deepcopy instead of delayed evaluation. I guess I'll write a comment on his answer for that. – magu_ Jun 12 '17 at 21:21

0 Answers0