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
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/YTLTLYFTKNRRJXYAA6GJRBJWCSNOMXAX/ Code of Conduct: http://python.org/psf/codeofconduct/
