syntax for code blocks

[Ian Kelly]

On Thu, May 3, 2012 at 10:17 AM, Kiuhnm
<kiuhnm03.4t.yahoo.it at mail.python.org> wrote:
> On 5/3/2012 2:20, alex23 wrote:
>>
>> On May 2, 8:52 pm, Kiuhnm<kiuhnm03.4t.yahoo.it>  wrote:
>>>>
>>>>      func(some_args, locals())
>>>
>>>
>>> I think that's very bad. It wouldn't be safe either. What about name
>>> clashing
>>
>>
>> locals() is a dict. It's not injecting anything into func's scope
>> other than a dict so there's not going to be any name clashes. If you
>> don't want any of its content in your function's scope, just don't use
>> that content.
>
>
> The clashing is *inside* the dictionary itself. It contains *all* local
> functions and variables.

Since all locals within a frame must have different names (or else
they would actually be the same local), they cannot clash with one
another.


>> Because under no circumstance does "with function_name as
>> string_signature" _read_ in an understandable way. It's tortuous
>> grammar that makes no sense as a context manager. You're asking people
>> to be constantly aware that there are two completely separate meanings
>> to 'with x as y'.
>
>
> The meaning is clear from the context. I would've come up with something
> even better if only Python wasn't so rigid.

It's really not very clear.  I think the biggest difficulty is that it
effectively reverses the roles of the elements in the with statement.
The usual meaning of:

with func():
    do_stuff

is that func is called to set up a context, and then the block is
executed within that context.  The modified meaning is that the block
is gathered up as a code object and then passed as an argument into
func (despite that func *appears* to be called with no arguments),
which may or may not do something with it.  In the former, the
emphasis is on the code block; func is effectively an adverb.  In the
latter, func describes the main action, and the code block is the
adverb.

For that reason, I think that this would really need a brand new
syntax in order to gain any real acceptance, not just a complicated
overload of an existing statement.  For that you'll need to use a
preprocessor or a compiler patch (although I'm not denying that the
run-time module rewriting is a neat trick).