>> The problem with this syntax is that you still need a local keyword within functions in order to avoid namespace collisions.
> I was hoping my intention would be clear. I precisely want both local and global, at the same time. If you use a variable without a declaration using the existing lexical scoping, it would be an error.
You didn't use the local keyword in your example, so I thought you were specifying a different syntax for local-by-default. My apologies.
> By the way, "global" can be misleading indicating truly global variables. I would prefer to use "nonlocal" which indicates upvalue/global.
If there must be a keyword then I agree that "global" is a bad choice, although I think that "nonlocal" is a terrible name whose only saving feature is its consideration in Python. I personally lean more towards "extern" or "outer" or "use" or something.
> The issue is, people generally don’t like typing that much and they don’t like being forced to make decisions about scope when everything can just be global. I personally feel differently, so typing a bit more isn’t so bad.
It's not about typing. Most people don't actually have a problem with the act of typing, as is evidenced by things like comments, whitespace, and descriptive function and variable names. The real problem is in the mental overhead necessary to juggle additional language constructs and additional rules, and your "global" keyword introduces a new level of scope that didn't exist before. After all, unless you're talking about a TRUE global, then the global keyword would have exactly the same scoping as the local keyword. And if you're talking about true globals, that's what _ENV is for, so there's no need to add a new language concept.
/s/ Adam
