Late-binding of function defaults (was Re: What is a function parameter =[] for?)

Antoon Pardon antoon.pardon at rece.vub.ac.be
Wed Nov 25 07:25:23 EST 2015


Op 25-11-15 om 11:52 schreef Steven D'Aprano:
> On Wed, 25 Nov 2015 07:14 pm, Antoon Pardon wrote:
>
>> Op 20-11-15 om 01:33 schreef Steven D'Aprano:
>>> On Fri, 20 Nov 2015 07:57 am, Marko Rauhamaa wrote:
>>>
>>>> Laura Creighton <lac at openend.se>:
>>>>
>>>>> My experience says that the people who are confused want lists to
>>>>> behave like tuples. period. i.e. they don't want lists to be mutable.
>>>> I think it's simpler than that. When you have:
>>>>
>>>>    def f(x=[]):
>>>>        y = []
>>>>
>>>> the first [] is evaluated when "def" is executed, while the latter [] is
>>>> evaluated whenever "f" is executed. It's easy to be confused.
>>> It shouldn't be. The function declaration
>>>
>>>     def f(x=[]):
>>>
>>> is executed only once. The function body, conveniently indented to make
>>> it stand out:
>>>
>>>         y = []
>>>
>>> is executed every time you call the function.
>> What exactly is your point? 
> That there is a simple analogy between the distinction between code
> inside/outside a for-loop, and code inside/outside a function. If you can
> understand why this loops forever, instead of just twice, then you can
> understand why function defaults work the way they do:
>
> L = [1, 2]
> for i in L:
>     L.append(i)
>     print(L)
>
>
> There is nothing "bizarre" or complicated or difficult to understand
> happening here. It might not be what you want to happen. It might not be
> what you expect to happen. But if you can't understand why it happens even
> after multiple explanations, then your learning skills are severely
> lacking.

You shouldn't equate that what you understand with what is not bizarre
complicated or difficult.

I think there are reasons to find the above behaviour bizarre. I personnaly
don't find it bizarre, but that is because I'm familiar with what is going
on. But if someone expects the compilor to take a snapshot of L and iterate
over that I am not going to say he shouldn't have expected that.

And IMO each time you proclaim something nothing bizarre or complicated
or difficult you are not helping.

>> People's confusions don't disappear 
>> because you as an expert have a good understanding of what is
>> going on and so are no longer confused.
> I'm an expert? Awesome!
>
> No. But people's confusion would disappear if they would:
>
> - think about the process
> - try to follow the steps of what is happening
> - pay attention to the explanations given
> - and ask for clarification instead of arguing.

People would be more inclined to do so, if there wasn't someone
claiming there was nothing bizarre or complicated or difficult
going on. Telling the above is implying those steps are not
needed because it is obvious what is happening. And if you
don't want people arguing, don't start yourself. Because my
impression of what is most likely to happen when someone says
something like: That is bizarre, is that the regulars here
are the ones that start arguing about it not being bizarre
and then they are annoyed that the other is arguing too.

> I have come to the conclusion that there is nobody as stupid as an
> intelligent person who refuses to learn.

Sure but that works just as much for the regulars here, who despite
that some subjects keep confusing people new to the language, keep
repeating that there is nothing bizarre, complicated or difficult
going on.

>> Some aspects in the langauage are easily grasped and other
>> aspects tend to create confusion. 
> You're right. Some aspects of the language are inherently confusing and hard
> to reason about. Threads are an example of that. The more powerful, and
> tricky, aspects of regular expressions. The weird stuff that happens during
> interpreter shutdown if you have __del__ methods in your objects. __del__
> methods in general. There are many things which are hard to reason about,
> and therefore confusing.
>
> *This is not one of them.*

Please stop using your personal evaluation as if it is some kind of
objective measure. The number of people that seem to get confused by
this, contradicts your claim.

> But is it predictable or intuitive? No, I agree, this behaviour is not
> intuitive, if you are coming from a background without equivalent rules. I
> will completely grant you that most people without Python experience would
> not correctly predict the behaviour of mutable defaults.
>
> I was caught out on that too, as I already admitted. Even though I already
> knew all the facts I needed to predict the behaviour correctly, I didn't
> put 2+2 together and get 4. That's *my bad*, not the language's fault.

Why not? People are not perfect rational thinking machines. And expecting
them to act like ones in order to get the language out of the wind, is
a rather weak argument IMO.

> How much harder must it be for those who don't know the essential facts? I
> don't expect anyone to intuit the behaviour of Python defaults. That would
> be unreasonable. There's no shame in guessing wrong from a position of
> ignorance.
>
> Me, on the other hand... I should have known better. I did know better.
>
> But there's a big difference between those who guess wrong from a position
> of ignorance, and then make an honest attempt to understand the behaviour
> and why it actually does make sense and is even sometimes useful (even if
> they don't like it), and those people who insist that it is nonsensical,
> magical and "bizarre".

There is an equally big difference between trying to explain what is going
on and insisting that what is going on is not bizarre.

-- 
Antoon.




More information about the Python-list mailing list