[Python-ideas] If branch merging

Nick Coghlan ncoghlan at gmail.com
Thu Jun 11 03:16:00 CEST 2015


On 10 June 2015 at 10:54, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, Jun 10, 2015 at 10:20 AM, Andrew Barnert via Python-ideas
> <python-ideas at python.org> wrote:
>> Now, for implementation: any statement that contains an as expression anywhere is compiled to a function definition and a call to that function. The only trick is that any free variables have to be compiled as nonlocals in the inner function and as captured locals in the real function. (This trick doesn't have to apply to lambdas or comprehensions, because they can't have assignment statements inside them, but a while statement can.) I believe this scales to nested statements with as-bindings, and to as-bindings inside explicit local functions and vice-versa.
>>
>
> I'd actually rather see this implemented the other way around: instead
> of turning this into a function call, actually have a real concept of
> nested scoping. Nested functions imply changes to tracebacks and such,
> which scoping doesn't require.
>
> How hard would it be to hack the bytecode compiler to treat two names
> as distinct despite appearing the same?

I tried to do this when working with Georg Brandl to implement the
Python 3 change to hide the iteration variable in comprehensions and
generator expressions, and I eventually gave up and used an implicit
local function definition:
https://mail.python.org/pipermail/python-3000/2007-March/006017.html

This earlier post from just before we started working on that covers
some of the approaches I tried, as well as noting why this problem is
much harder than it might first seem:
https://mail.python.org/pipermail/python-3000/2006-December/005207.html

One of the other benefits that I don't believe came up in either of
those threads is that using real frames for implicit scoping means
that *other tools* already know how to cope with it - pdb, gdb,
inspect, dis, traceback, etc, are all able to deal with what's going
on. If you introduce a new *kind* of scope, rather than just
implicitly using another level of our *existing* scoping rules, then
there's a whole constellation of tools (including other interpreter
implementations) that will need adjusting to model an entirely new
semantic concept, rather than another instance of an existing concept.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list