What is a function parameter =[] for?

[BartC]

On 22/11/2015 03:43, Steven D'Aprano wrote:
> On Fri, 20 Nov 2015 10:59 pm, BartC wrote:
>
>> On 20/11/2015 01:05, Steven D'Aprano wrote:
>
>>> Here's another use for function defaults, as static storage:
> [...]
>>> This is a quick and easy way to memoise a function which would otherwise
>>> be horribly slow. And it only works because _memo is bound to a mutable
>>> object once, and once only.
>>
>> We're arguing at cross-purposes then since you are obviously interested
>> in these esoteric aspects,
>
> Memoisation isn't "esoteric", it is a simple, basic and widely-used
> technique used to improve performance of otherwise expensive functions.

Ackermann is esoteric and so is memoisation, or at least the term is.

(I use the Ackermann function frequently, but usually as a benchmark 
measuring how good a language implementation is at function calls, 
especially recursive ones. And how well it copes with large recursion 
depth. Adding memoisation would defeat the purpose!)

But if it's used for static storage, then why not just use static 
storage? That's a simpler and more general concept than memoisation.

If Python's 'default values' are just a device for obtaining local 
static storage which are otherwise not possible, then why not use 
terminology to say so? As I guess it's too late to do anything about the 
syntax.

(Of course it won't be quite the same, as the caller can overwrite the 
local and /private/ 'static' variables at any time, but I suppose that 
would be yet another feature!)

> Quite frankly, to call it such demonstrates a considerable level of
> ignorance about basic programming idioms. Not just Python, but general
> purpose programming.

I've come to learn that basic idioms are best. Especially trying to 
understand someone else's code (or to translate into another language 
with a different set of advanced features). Some people delight in 
pulling out all the stops and using all the advanced features of a 
language to the hilt. With the result being very concise and clever 
code, but completely unreadable.

>> (Here, however, the language doesn't like you doing in-place
>> modification of a parameter unless the '&' is used,

> It sounds to me like you have implemented something like Pascal's "var"
> parameters, is that right? I believe some languages (VB perhaps?) call
> them "output parameters".

(Something like that. Python seems to exclusively to push around 
references to objects. I use a mix of value objects and part-references. 
The & is an indication to use full references. I can also use actual 
pointers, but I'm trying to get away from that.)

>> OK, so the "=" is misleading if not a lie.
>
> No. Why would you conclude that? If I called the function like so:
>
>      test( [1, 2, 3, 4, 5] )
>
> and got the result 6, would I conclude that the "=" is misleading if not a
> lie? After all, the function declaration clearly shows arg being assigned
> the value [], so why am I getting 6 as the result instead of 1?

That's being silly. We all know this is default value syntax. The lie is 
the [] not necessarily being the default value on every call.

> The whole point of parameter default arguments is that they are bound to the
> parameter *only* if the parameter otherwise isn't given a value. That's a
> separate issue from *when* the default expression is evaluated.

No, that is at the heart of matter. And it's not just a question of 
'when' the 'binding' is done, but the fact that, even if we accept that 
the default value is evaluated when the function is defined, that value 
can then subsequently change.

We all know now /why/ it can do so, which is an unfortunate consequence 
of how it's implemented. But you seem very keen to show it in a positive 
light. It's a feature, not a bug!

>> In my language, a construct such as [10,20,30] is evaluated just once at
>> start-up.
>
> I don't understand that explanation. How does that work? Given:
>
> x = [10, 20, 30]
> y = [10, 20, 30]
>
>
> how does your language know what value y has if it doesn't evaluate the
> second construct?

(It generates some start-up code which assigns [10,20,30] to a variable. 
Then that variable is used in place of that particular [10,20,30]. (It 
doesn't combine multiple instances of the same constant list, as that is 
not common. So y would be dealt with separately.)

I think Python already does something along these lines for tuples, 
which cannot change. It means you're executing a simple LOAD instead of 
BUILT_LIST on N values.)

-- 
Bartc