On 21/06/2013 19:26, Rick Johnson wrote:
On Friday, June 21, 2013 12:47:56 PM UTC-5, Rotwang wrote:
It isn't clear to me from your posts what exactly you're
proposing as an alternative to the way Python's default
argument binding works. In your version of Python, what
exactly would happen when I passed a mutable argument as a
default value in a def statement? E.g. this:
>>> a = [1, 2, 3]
>>> a.append(a)
>>> b = object()
>>> def f(x = [None, b, [a, [4]]]):
... pass # do something
What would you like to see the interpreter do in this case?
Ignoring that this is a completely contrived example that has
no use in the real world, here are one of three methods by
which i can handle this:
I didn't ask what alternative methods of handling default argument
binding exist (I can think of several, but none of them strikes me as
preferable to how Python currently does it). I asked what would happen
in /your/ version of Python. Which of the alternatives that you present
would have been implemented, if you had designed the language?
============================================================
The Benevolent Approach:
============================================================
I could cast a "virtual net" over my poor lemmings before
they jump off the cliff by throwing an exception:
Traceback (most recent screw-up last):
Line BLAH in SCRIPT
def f(x = [None, b, [a, [4]]]):
ArgumentError: No mutable default arguments allowed!
So how does the interpreter know whether an arbitrary object passed as a
default value is mutable or not?
Not that it really matters. Elsewhere in this thread you wrote:
Let's imagine for a second if Python allowed mutable keys in
a dictionary,
which it does
would you be surprised if you used a mutable
for a key, then you mutated the mutable key, then you could
not access the value from the original key?
## Imaginary code ##
py> lst = [3]
py> d = {1:2, lst:4}
py> lst.append(10)
py> d[lst]
opps, KeyError!
Would you REALLY be so surprised? I would not. But more
importantly, does Python need to protect you from being such
an idiot? I don't think so!
Now, I don't really believe that you think that the user shouldn't be
protected from doing one idiotic thing with mutable dict keys but should
be protected from doing another idiotic thing with mutable default
arguments, especially as you've already been given a use case for the
latter. So I assume that The Benevolent Approach is not the approach you
would have gone for if you had designed the language, right? If so then
let's ignore it.
============================================================
The Apathetic Approach:
============================================================
I could just assume that a programmer is responsible for the
code he writes. If he passes mutables into a function as
default arguments, and then mutates the mutable later, too
bad, he'll understand the value of writing solid code after
a few trips to exception Hell.
It seems to me that this is exactly what currently happens.
============================================================
The Malevolent Approach (disguised as beneva-loon-icy):
============================================================
I could use early binding to confuse the hell out of him and
enjoy the laughs with all my ivory tower buddies as he falls
into fits of confusion and rage. Then enjoy again when he
reads the docs. Ahh, the gift that just keeps on giving!
My question was about how you think the language should work, not about
what your buddies should or shouldn't enjoy. In terms of how a language
actually works, is there any difference between The Malevolent Approach
and The Apathetic Approach? And is there any difference between either
of them and what Python currently does?
============================================================
Conclusion:
============================================================
As you can probably guess the malevolent approach has some
nice fringe benefits.
You know, out of all these post, not one of you guys has
presented a valid use-case that will give validity to the
existence of this PyWart -- at least not one that CANNOT be
reproduced by using my fine examples.
Of course using a mutable default as a cache can be reproduced by other
means, as can another common use case that I don't think anyone's
mentioned yet (defining functions parametrised by variables whose values
aren't known until runtime). That's hardly an argument against it - you
might as well argue that Python shouldn't have decorators, or that it
shouldn't have for loops because their behaviour can be reproduced with
while loops.
But this is beside the point anyway, until you present an alternative to
Python's current behaviour. If you do so then we can start debating the
relative merits of the two approaches.
--
http://mail.python.org/mailman/listinfo/python-list
