nonlocal fails ?

[Chris Angelico]

On Fri, Nov 15, 2019 at 7:19 AM Michael Torrie <torriem at gmail.com> wrote:
>
> On 11/14/19 10:57 AM, R.Wieser wrote:
> >> I know of no sane way that a function could work with the scope of
> >> any arbitrary caller.
> >
> > The trick seems to be to emulate a "by reference" call, by using a mutable
> > object as the argument and stuff the value inside of it (IIRC a tuple with a
> > single element).
>
> Right. You could pass in a dict as an argument. You could even pass in
> the caller's locals() dictionary.  I'm not sure I recommend the latter
> approach, however.

The locals() dict isn't guaranteed to be mutable. At the moment, there
are very very few actual language guarantees regarding changes to
locals(), but there's currently a WIP to define things a little more
tightly:

https://www.python.org/dev/peps/pep-0558/

Neither in the current wording nor in the proposed wording is any sort
of promise that you could pass locals() to another function and have
it usefully modify that.

> I'm coming more and more around to some of the ideas of functional
> programming.  Doing as you suggest, reaching back to the caller's
> variables, sounds extremely messy to me.  And very fragile, hard to
> test, and doesn't lend itself to easily extended functionality by
> chaining(think unix-style piping).
>
> I find Python's ability to return tuples virtually eliminates any need I
> have to "pass by reference."

Agreed. Or Python's ability to return strings. Most of the
pass-by-reference that I do in languages like SourcePawn is just to
get around the problem that strings aren't first-class values.

> I'm coming around to the idea that wherever possible, functions should
> have no side effects.  Those things that need side effects should be
> isolated so they are easy to maintain.  I believe they call this "push
> side effects to the edges."

Something like that. Ideally, a function should be pure - having no
side effects, being unaffected by external state, and having a return
value determined entirely by its arguments. Not every function can be
pure, of course (for instance, print() is most certainly NOT a pure
function), but the more of your functions that are pure, and the purer
your other functions are, the easier it is to reason about your code
and refactor things.

ChrisA