[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

Raymond Hettinger added the comment: The advent of the LOAD_METHOD opcode addresses this issue. -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker

[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

Change by Yonatan Goldschmidt : -- nosy: +Yonatan Goldschmidt ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

Mark Lawrence added the comment: Is this ever likely to be implemented or is it more likely to be rejected owing to the reasons given in msg75587 ? -- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org

[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

Changes by R. David Murray rdmur...@bitdance.com: -- type: - feature request versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4264 ___

[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

David Turner [EMAIL PROTECTED] added the comment: FWIW, I see exposing bytecodes as an anti-pattern that locks in a particular implementation in a way that makes it hard to change and hard to port to other Python implementations. The current bound method approach works fine. Don't really

[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

David Turner [EMAIL PROTECTED] added the comment: Obviously if there's another sufficiently good argument for the visitor approach, I'm all ears. But again, if we do that I think we should do it for the compiler as well. I'm not sure how much support such a change would have. The argument

[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

David Turner [EMAIL PROTECTED] added the comment: Neal Norwitz [EMAIL PROTECTED] added the comment: Interesting approach. I was surprised to see the change to the AST, but I understand why you did it. I think if the AST optimization approach works out well, we will want to have some

[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

David Turner [EMAIL PROTECTED] added the comment: Actually, I just noticed a case where the code would do the wrong thing. I fixed it and added a test for it. Added file: http://bugs.python.org/file11958/tlee-ast-optimize-appends-3.diff ___ Python tracker

[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

Raymond Hettinger [EMAIL PROTECTED] added the comment: I really didn't want to have to change the AST. The problem was that there was a feature of the Python bytecode which was not representable in Python source code. FWIW, I see exposing bytecodes as an anti-pattern that locks in a

[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

Thomas Lee [EMAIL PROTECTED] added the comment: Neal said: I was surprised to see the change to the AST, but I understand why you did it. The problems David ran into here sound like an argument for arbitrary AST annotations -- an idea that I was toying with around the time Const was

[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

New submission from David Turner [EMAIL PROTECTED]: This is a patch to Tom Lee's AST optimization branch. Python bytecode includes at least one operation which is not directly accessible from Python code: LIST_APPEND, which pops a value and a list off the stack and appends the value to the

[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

Neal Norwitz [EMAIL PROTECTED] added the comment: Interesting approach. I was surprised to see the change to the AST, but I understand why you did it. I think if the AST optimization approach works out well, we will want to have some more general mechanism to communicate these optimization (or