Danceswithmice wrote:
The larger criticism of the above is the chosen-name
The name is irrelevant; an extremely minor implementation detail, and one that is meaningless if the idea itself does not pass muster. Users would not see the name in any case; it's an interpreter level issue. So on with the concept, then:
However, deliberating over the choice of name for the function makes the code easy to read
The idea is that YOU write "local:", and the interpreter, without you ever seeing it, promotes that into a hidden function with a hidden name and a hidden call. --- p.f.moore wrote:
That would make "return" in the local scope exit the scope, not the enclosing function. Which is almost certainly not what people would expect from a "local scope" statement.
Hence my remark about return and yield requiring attention. These would be disallowed in the context of "local:" UNLESS there is an enclosing scope of "def function():", so there's no issue of what they do if they are simply mainlined, and (I think) a well defined result if they are not. --- rosuav wrote:
Not sure what you mean about "mak[ing] sure return and yield were appropriate" though. Inside such a local block, are you expecting yield and return to apply to the outer function?
I would expect them to return to, or yield to, the next outer "def" function, assuming they were in a "local:" inside another function. I would expect return and yield to be outright disallowed otherwise. I would also expect that the interpreter would know very well how deep it is in functions, generated or programmer defined.
For a much, MUCH easier way to give semantics to this
for local MyVariable in range(0,10): Yes, that could work. It requires more declarations (one per variable, right?) than declaring an entire block local to limit the scope(s), but that's the only issue I see. The ability to create non-colliding local variables is the endgame benefit either way. The name-mangling... low level interpreter action, if done well, we'd never see it. It could live in un-mangled form in its own collection. --- I've written a Python pre-compiler (primarily in order to allow extending the string class, which has some annoying tight couplings to "string" and 'string') I wanted to work around; I think I'll add "local:" to it and see how that feels. Thanks for everyone's input. --Ben