On Sat, 15 Nov 2008 21:29:22 -0800, Aaron Brady wrote:
> I don't think Dennis or Steven read your post very well.
It's possible.
> You said 'Why
> does Python do X?', and 'It seems natural to you to do not X'. Dennis
> and Steven both said, 'Python does X'.
I also disputed that it is natural to do not-X (runtime creation of
default arguments), and explained why such an interpretation doesn't
match with the way Python operates. I admit I didn't answer the "why"
part.
> Steven did get around to suggesting an answer though. He said:
>
>> If you want something to be
>> created each time the function is called, you have to put it inside the
>> body of the function:
If you want to be pedantic, then my "answer" (which you seem to approve
of) doesn't correspond to either of the original poster's questions. If
you're going to be pedantic, then be pedantic all the way, and criticize
me for answering a question that wasn't asked :-P
> Taking this to be true, the answer to your question is, 'Because the
> object isn't created inside the body of the function,' or, 'Because the
> argument list is outside the body of the function'.
Actually, the correct answer to "Why?" would be "Because that's the
decision Guido van Rossum made back in the early 1990s when he first
started designing Python". That of course leads to the obvious question
"Why did he make that decision?", and the answer to that is:
* it leads to far more efficient performance when calling functions;
E.g. if the default value is expensive to calculate, it is better to
calculate it once, when the function is created, than every single time
the function is called.
Additionally, the effbot once mentioned in a similar thread that there
are real performance benefits in the Python VM from binding the default
value once only. I don't know the exact details of that, but I trust
Fredrik knows what he's talking about.
* it has less scope for surprise when calling functions.
E.g. I would argue that most people would be surprised, and dismayed, if
this code fails:
x = 1
def foo(a, b=x):
return a+b
del x
print foo(2)
> From your post, it's hard to tell whether this 'duh'-type observation
> would point out the salient feature of the construct, or whether you're
> after something deeper.
>
> If you're asking, 'Why isn't the argument list considered to be inside
> the body?', then the answer is, it's pretty much arbitrary.
No, it is not an arbitrary choice. I've given practical reasons why the
Python choice is better. If you want default argument to be created from
scratch when the function is called, you can get it with little
inconvenience, but the opposite isn't true. It is very difficult to get
static default arguments given a hypothetical Python where default
arguments are created from scratch. There's no simple, easy idiom that
will work. The best I can come up with is a convention:
# Please don't change this, or strange things will happen.
_private = ResultOfExpensiveCalculation()
def foo(a, b=_private):
return a+b
The above is still vulnerable to code accidentally over-writing _private
with some other value, or deleting it, but at least we avoid the
expensive calculation every time.
Or possibly:
def foo(a, b=foo._private):
return a+b
foo._private = ResultOfExpensiveCalculation()
which has obvious disadvantages with regard to shadowing, renaming,
anonymous functions, and so forth.
> Regardless
> of which one the author of Python chose, the other's workaround would be
> equally short,
Not true. One has an obvious workaround, the other only has a *partial*
workaround.
> and neither one is obviously indicated by the syntax.
I would disagree, but not enough to argue.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
