Alex Martelli <aleaxit at yahoo.com> writes: > Assume for the sake of argument that we could make 'scope' a reserved > word. Now, what are the tradeoffs of using a "declaration" > scope x in outer > which makes all rebidings of x act in the scope of containing function > outer (including 'def x():', 'class x:', 'import x', ...); versus an > "operator" that must be used to indicate "which x" when specifically > assigning it (no "side effect rebinding" via def &c allowed -- I think it > helps the reader of code a LOT to require specific assignment!), e.g. > scope(outer).x = 23 > > Don't think of scope as a built-in function, but as a keyword in either > case (and we could surely have other syntax for the "scope operator", > e.g. "(x in outer scope) = 23" or whatever, as long as it's RIGHT THERE > where x is being assigned). So the compiler can catch on to the info > just as effectively. I'm skimming this, so I apologise if I've missed something obvious. However, one significant issue with your notation scope(outer).x = 23 is that, although scope(outer) *looks like* a function call, it isn't - precisely because scope is a keyword. I think that, if you're using a keyword, you need something syntactically distinct. Now maybe you can make something like (x in f scope) work as an expression (I've deliberately used "f" not "outer" to highlight the fact that it may not always look as "nice" as your example), but I'm not sure it's as intuitive as you imply. But then again, I've no problem with "global x in f". Paul -- This signature intentionally left blank
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4