On 2/13/07, Chris Rebert <[EMAIL PROTECTED]> wrote: > This PEP proposes new semantics for default arguments to remove > boilerplate code associated with non-constant default argument values, > allowing them to be expressed more clearly and succinctly. > Specifically, > all default argument expressions are re-evaluated at each call as > opposed > to just once at definition-time as they are now.
Seems like a huge barrel of worms. The binding semantics are not only a problem for mutable arguments, as you state in your pep: In [2]: def a(): ...: g = 1 ...: def b(): ...: print g ...: g = 2 ...: return b ...: In [4]: a()() 2 In [5]: def a(): ...: g = 1 ...: def b(g=g): ...: print g ...: g = 2 ...: return b In [6]: a()() 1 Creating closures and define-time local bindings is certainly not as common as a "regular" function definition, it is important part of python when programming in a semi-functional style. Imagine that "def b" is in a for loop. Your presented alternatives either don't work or go to rather extreme effort to duplicate this simple and useful functionality. I agree that newbies stumble over mutable default arguments. I did. If we could improve that learning process, I would be all for it. However, besides this being a significant change in semantics, two main stumbling blocks in my mind are: 1. Scoping. Scoping issues are not minor consequences of changes to default argument behaviour, but are integral. I think that you'd have to come up with a more obvious way to accomplish all the various current behaviours of def args before changing their semantics. This is probably a larger project than the original proposal. 2. Performance. The speed of python is influenced greatly by the performance of function dispatch. This may not show up in pystone. -Mike _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
