[Python-ideas] If branch merging
ncoghlan at gmail.com
Thu Jun 11 03:30:37 CEST 2015
On 11 June 2015 at 11:16, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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:
Re-reading that post, I found this:
I don't think anyone has yet tried speeding up simple function level
cases at the peephole optimiser stage of the code generation pipeline
(at module and class level, the nested function is already often a
speed increase due to the use of optimised local variable access in
the implicitly created function scope).
However, I'm not sure our pattern matching is really up to the task of
detecting this at bytecode generation time - doing something about in
a JIT-compiled runtime like PyPy, Numba or Pyston might be more
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas