What is a function parameter =[] for?

Mark Lawrence breamoreboy at yahoo.co.uk
Thu Nov 19 13:26:08 EST 2015


On 19/11/2015 18:19, BartC wrote:
> On 19/11/2015 17:45, Chris Angelico wrote:
>> On Fri, Nov 20, 2015 at 4:30 AM, BartC <bc at freeuk.com> 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([])
>>>
>>> You just write fn() instead. But it shouldn't come at the cost of
>>> completely
>>> different semantics! Because then it can't really be called a default
>>> value
>>> at all.
>>>
>>
>> Do you understand the concept of "mutable objects"? Don't even try to
>> discuss mutable function defaults until you do.
>
> Yes. In the languages I create, pretty much everything is mutable,
> provided it can supply an l-value. Constructs such as those for empty
> lists ([] in Python, () in mine) aren't l-values.
>
> But it doesn't apply default values. The language is very different
> however, because the byte-code compiler always has full knowledge of
> functions that are called directly. Then it knows when an argument is
> omitted, and can simply substitute the expression used as the default.
>
>> If your language simply has no mutable objects, then sure, it's easy
>> to understand function defaults! There's no such thing as early or
>> late binding; in fact, you can even super-late-bind, where you don't
>> actually call a function until its *return value* is being used (as
>> long as that function has no side effects). But as soon as objects are
>> capable of retaining their identities while changing their values, you
>> need an object model that (a) distinguishes between identity and
>> value, and (b) allows some definition of early or late binding,
>> because it *will* matter.
>>
>>> if you write A=B then something of B needs to have been copied into
>>> A, even if it's just the reference that B contains. Otherwise it
>>> would be
>>> difficult to get A to refer to the same object as B.
>>
>> Please, PLEASE, go and read/watch Ned's PyCon talk (the one I linked
>> you to earlier). Don't post another word on this subject until you
>> comprehend what he is saying.
>
> I looked through the long article (I don't remember seeing a link to a
> video), and followed it up to about 3/4 of the way through, then it got
> a bit heavy.
>
> But what is it about my remarks above that isn't right?
>

To summarize, it once again shows that you haven't got the faintest idea 
what you're talking about.  You're now in a very exclusive club with the 
RUE and Nick the Greek, the world's leading webmaster.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence




More information about the Python-list mailing list