3 ms·
... is this any different than a function like this: greet("hello {world}") which walks the call stack to find the variables, and uses them as locals / ar
by Groxx 2y ago
... is this any different than a function like this:
greet("hello {world}")
which walks the call stack to find the variables, and uses them as locals / arguments?
If so: why not just do that? I would expect the performance to be kinda terrible compared to a language-intrinsic, but this hardly seems like a thing worth truly optimizing. And if it's too costly at runtime, someone can implement a parse-time AST rewriter, like many Python things already do. Heck, that example's `assert` is probably using pytest (because everyone uses pytest) and it's doing exactly this already, and it isn't a language feature, it's just a normal library using normal Python features.
- jimbaker 2y agoWalking the call stack implies using dynamic scope, which has hard edges, vs lexical scope. See my answer earlier in this thread https://news.ycombinator.com/item?id=41272285 https://news.ycombinator.com/item?id=41272285 It's been nearly 23 years, but Python 2.2 fixed this issue (https://docs.python.org/3/whatsnew/2.2.html#pep-227-nested-scopes https://docs.python.org/3/whatsnew/2.2.html#pep-227-nested-s...), and it's also why JavaScript added let (and const). f-string support also uses lexical scope, and it's an important part of its success.