On Jun 27, 2019, at 16:18, Greg Ewing firstname.lastname@example.org wrote:
Andrew Barnert wrote:
in Lisp, if you replace the setf macro,
Okay, maybe Lisp wasn't a good example. In the presence of macros, all bets are off. :-( But at least if you haven't redefined the universe, local bindings in Lisp behave predictably.
Right, but if you haven’t redefined the universe, global (and dynamic and so on) bindings behave predictably too. There’s nothing special about locals that makes them untouchable, or even harder to touch, then any other namespace.
And I think that’s more typical among name-binding languages than Python’s “locals are special, nobody can touch them”. Python’s behavior seems to be mainly a side effect of the fast-locals optimization. (That restrictive side effect might well be a good thing for people maintaining 10-year codebases and trying to keep them readable, but those are usually not the kind of benefits that other language designers steal from Python.)
If you had code involving “x = 2” that stopped working when you moved it from local to a module init function to the top level ... would you think “That’s ok, x isn’t local, so I wasn’t expecting assignment to mean binding”?
I wouldn't think "x isn't local", because it still is local from the point of view of that piece of code.
That’s great way to put it.
And that’s why I think if it’s not acceptable to add these books to locals, it’s at least questionable behavior for globals (or, conversely, if it is acceptable to hook global this way, it should be acceptable to hook locals too). There are ways in which locals and global act differently, for good reasons—but otherwise, they act as similarly as possible, which is what allows you to think of globals as local to global code.