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

[BartC]

On 27/11/2015 01:09, Steven D'Aprano wrote:
> On Thu, 26 Nov 2015 12:23 pm, BartC wrote:

[First-class functions]
>> The names are declared, but the names are rarely bound to anything else.
>> Functions are just called the same boring way they are in C.
>>
>> /They might as well be static definitions/.
>
> Sure. And that's probably true for, oh, I don't know, I'll be generous, and
> say that 95% of Python functions in use are of a straight-forward
> pseudo-static form, using no dynamic features.
>
> But it's the other 5% -- one in twenty -- that *shine*. They're the ones
> that do things that you can't do in Pascal or C except with the greatest of
> difficulty.

OK, you're worried about that 5%, I'm more concerned about the other 95%.

I'm not saying you shouldn't have dynamic functions at all, just that 
it's not necessary for 100% to be dynamic.

I understand now that they are dynamic because that is the only 
mechanism that Python has to create any function definition, even the 
boring, static ones.

Together with the ability to subsequently re-bind the function name to 
something else, that's a bit unfortunate because it makes it harder to 
identifier calls to those functions in order to streamline them, or even 
for someone to look at a bit of code and be sure whether that fn(a,b,c) 
is calling the function defined as 'fn' a few hundred lines earlier or 
something else entirely.

(MRAB mentioned Postscript, which also introduces functions using 
executable statements.

However, Postscript was designed to execute code on-the-fly being 
received a character at a time over a printer cable. It had a good excuse!)

> Because Pascal doesn't have first-class functions, you couldn't pass a
> function as an argument to another function. So the ODE solvers used a
> hard-coded function as the equation to be solved. So if you wanted to solve
> a particular equation, you had to *edit the source code of the program*,
> modifying that hard-coded function to match your equation, then re-compile,
> and then run the code. You couldn't just type in the equation you wanted to
> solve and run the code.

Wouldn't Python have the same problem? If the equation to be solved, or 
even the actual function to be executed, is input by the user, then 
doesn't that require whichever one of exec() or eval() it is that 
processes the source code?

> There's a lot to like about Pascal,

It was designed for teaching. The original language would have needed 
tweaking for use in general purpose programming.

> but gosh it sure is lacking in power. C
> at least has function pointers, which is a step up from Pascal, but still
> pretty weak and feeble. If functions are first class values in Python,
> Ruby, Lisp and others, they're second class values in C and third class in
> Pascal.

I think they are more first class in Lisp than they are in most other 
languages including Python. That doesn't stop Python still being jolly 
useful though...

-- 
Bartc