Syntax Suggestion: Pass Function Definition as Argument

[Stephen Waldron]

Ok firstly, this idea was inspired specifically by a project I'm working on for school concerning linked lists, in which I was trying to create a method that performed a function on elements iteratively without having to navigate the list from the head each time (of course taking the function as a parameter). This project is intended to be a personal module for future use. 

In the process of this discourse here, however, I think I've found an alternative for this specific issue, (so thanks guys) but generally speaking, there were other times I've wanted to use functions as parameters, typically while making personal modules, like a purely Js button module I had made a few years back, and it was apparent that the only way to do so in Python was to define first, then pass, which I simply didn't like the idea of in the context of a module, short of defining each function before the module instances with `def temp(*args):` or some other generic name I won't use past the module function instance.

Now yes, as many of you have pointed out, there may exist other workarounds for various instances in which one may think to use a function as an argument. Multi-line lambdas are a very intriguing method for the broad topic, (thanks, they will be useful in the future ^ ^b ++), but as @Chris Angelico mentioned, they can't really be used as replacements for def, and from what I've experienced trying them out, it wasn't always clear what could be done for some of the lines one would want to write.

Finally, some clarification for @David Raymond
> Isn't this basically just defining a function... but without an argument list? How would that know what "str" is?

In my original post, I said:
> If they are not, they won't be assigned to, which would cause an error unless a default value is given. These parameters could be available for passing in the annexed function if mentioned when the parameter is called.

Nyeh, it's written poorly, but I guess I should clarify by saying that, per the proposal, arguments are inherent from the parent function to the annexed function if and only if that argument is assigned to when the annexed function is called as the parameter it fills in the parent function's definition. Of course it can also use all other variables within it's scope.

In the example you're referring to, this is done on line 3:
    foo (str = str1)
making foo inherit "str" from myFoo, which was given the default value " ".

(I would suppose another viable alternative would be using nonlocal as I'll example below)

Also you ask if it's just defining a function. In all of my examples, I use only one instance of the parent function (which is actually pretty useless), but the power in doing this actually lies in calling it in various locations and passing different arguments and annexing different functions (kinda what functions are for, haha). I might be hard-pressed to think of an example short of writing out a more complex program, but here is.. something?.. I guess simply assume runOpt(prompt, foo) is a previously defined function, and variables used in the annex are within the annexed function's scope, but prompt is not inherited:


runOpt ("Play Game"):
    getUserData()
    chr[0].id = 0
    time = 0
    score = 0

    scene = 1


runOpt ("How To Play"):
    nonlocal prompt

    loadBg()
    display(prompt)

    scene = 2


runOpt ("Settings"):
    checkDefaults()
    chr[0].id = 5

    scene = 3





N.B. on everything (also some TLs you could skip): 
This is just a suggestion, I think it would be nice for previously stated reasons (ease, aesthetics, function, yadda-yadda). I would still love to hear ways I could currently achieve things similar, as that is one of the things I look for from suggestions since "I don't know how to do x right now and have not previously found a solution" is implied, but one trigger I do have is a reply of "that is not the way it is" to a "this is how I think it should be" statement; doesn't give me any hint as to the merits or demerits of my thought, as flawed as it may indeed be, in logistics, implementation, practice etc. Can't really say anyone has done that quite yet, but just making it known, so "What you can try" and "The suggestion is impractical because..." responses are welcome. 

Also, one of the reasons for my suggestions is ease. The structure used is fairly common in Python, and thus fairly intuitive (I hypothesize at least). I know from experience that once you learn something, it becomes fairly easy and intuitive for you, but not necessarily for others and you sometimes forget the struggle you endured to get there. Of course I'm not saying others shouldn't have to learn to, but if there's a way to make it easier for others, I'd push it. Now I am still going to learn all about async, await, yield (which I think deserves more cred from what I can see so far), and lambda (cuz I wanna) but if I think learning and utilizing these would be a hindrance however minor for future developers, I'm gonna try to push something easier to go alongside them.