On Friday, November 20, 2015 at 7:40:37 AM UTC-5, BartC wrote:
> On 20/11/2015 12:12, Ned Batchelder wrote:
> > On Friday, November 20, 2015 at 6:59:54 AM UTC-5, BartC wrote:
> >> On 20/11/2015 01:05, Steven D'Aprano wrote:
> >>> On Fri, 20 Nov 2015 04:30 am, BartC wrote:
> >>>
> >>>> On 19/11/2015 16:01, Steven D'Aprano wrote:
> >>> [...]
> >>>
> >>>> The whole concept of 'mutable' default is alien to me. A default is just
> >>>> a convenient device to avoid having to write:
> >>>>
> >>>> fn(0) or fn("") or fn([])
> >>>
> >>> Says who?
> >>
> >> People who want to avoid having to write:
> >>
> >> fn(0) or fn("") or fn([])
> >
> > I think we all understand by now that you are unhappy with what happens
> > in Python with mutable defaults. We get it. You are not alone. Lots of
> > people are surprised by this. But it is how Python works.
> >
> > I'm not sure what your goal is at this point. Are you:
> >
> > 1) still unsure what the behavior is, or
> > 2) trying to understand why it behaves that way, or
> > 3) hoping to change Python, or
> > 4) trying to convince us that your language is better, or
> > 5) something else?
>
> Mostly 5. (With a bit of 4. However that language is not something I'm
> selling or pushing. It's just something different used as a contrast.).
>
> What's bothering me is:
Let me try to answer some of these.
>
> * The large amount of mumbo-jumbo used to describe what's going on
We try not to use mumbo-jumbo, we use terms that can be confusing
sometimes. This page was recommended early on in this thread:
http://nedbatchelder.com/text/names1.html It is my best attempt to
lay out many of the issues here. I hope you have had a chance to
read/watch it.
> * The insistence (I think largely from Steven) that the way this feature
> works is good rather than bad
I think the fairest summary is that the way this works is better than
the alternatives, when you take into account the desire to keep the
semantics of the language simple.
> * The refusal to acknowledge that the def fn(a=[]) syntax is misleading.
> (What value will a have when you call fn()? The true answer is that you
> can't tell.)
I completely agree with you that the syntax surprises people. Anyone who
claims that it isn't surprising is ignoring the abundant empirical evidence
that people new to Python (and even some who have been using it for a long
time) are surprised by this.
But it is not true that "you can't tell" what value a will have. You have
been surprised by it, but I am confident that if we could sit together, I
could explain to you what value you would get, and it would be clear to you.
You might not like the answer, and it might not be what you first imagined,
but it is not unpredictable.
> * The persistent nonsense that somehow [] is mutable (what happens is
> that [] is assigned to a variable, and /that/ is mutable) (And I will
> probably get some flak now because 'assign' and 'variable' are
> meaningless in Python!)
As others have explained, [] is a value, a list. Lists are mutable.
a = [] # Create an empty list
a.append(1) # and mutate that list.
If we don't agree on this, then please please please go and look at the
page I linked above. This is a central concept in Python, and we aren't
going to be able to get anywhere if we can't agree on this.
> * And above, where I lay out /why/ people want to use the feature, so
> that the function can take care of some details, even that is refuted.
I understand why you want to use the feature. It would be nice if it
came out the way you (and many others) want. But it doesn't.
--Ned.
--
https://mail.python.org/mailman/listinfo/python-list
