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
…
[View More]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
[View Less]
Barry wrote:
> The ways scoping works in python is very hard to change as you are asking
for i think was a major reason to reject.
Perhaps it isn't all that difficult;
For instance, a "local:" declaration could be treated as if it were "def
function()" with an immediately succeeding call as far as the interpreter
is concerned. That buys the scoping for (nearly) free.
We write...
local:
for MyVal in range(0,10)
pass
...interpreter codes that, out of sight, as:
def …
[View More]ghost_func_0000001():
for MyVal in range(0,10)
pass
ghost_func_0000001()
Might take a bit of fiddling to make sure return and yield were appropriate
[requiring an actual enclosing def function():], but other than that, it's
basically the same idea -- provides scoping, making it easier for us to
code, debug, and document, while significantly decreasing the likelihood of
variable collisions.
--Ben
[View Less]