[issue6101] SETUP_WITH

Raymond Hettinger added the comment: Yes, someone went nuts with renumbering. That is allowed but was probably unnecessary. That being said, users of opcodes should really use the names in opcode.py instead of the numbers themselves. -- nosy: +rhettinger ___

[issue6101] SETUP_WITH

Antoine Pitrou added the comment: > Well, I just checked, and from 2.3 to 2.6 opcodes were only added, > existing ones were never renumbered. > > 2.7 however reshuffled a bunch of them, for no apparent reason at all: LIST_APPEND was renumbered because it gained an argument. There are also new

[issue6101] SETUP_WITH

Thomas Vander Stichele added the comment: Well, I just checked, and from 2.3 to 2.6 opcodes were only added, existing ones were never renumbered. 2.7 however reshuffled a bunch of them, for no apparent reason at all: $ diff -au opcodes-2.6 opcodes-2.7 --- opcodes-2.6 2010-12-04 20:47:19.11003

[issue6101] SETUP_WITH

Antoine Pitrou added the comment: > Really ? Is this documented somewhere ? Do you know of any other case > where a number for an existing opcode was changed ? I can't find any > so far. Opcodes are an implementation detail. If you are fiddling with opcodes, how will your code work under Jython

[issue6101] SETUP_WITH

Thomas Vander Stichele added the comment: Really ? Is this documented somewhere ? Do you know of any other case where a number for an existing opcode was changed ? I can't find any so far. -- ___ Python tracker __

[issue6101] SETUP_WITH

Benjamin Peterson added the comment: 2010/12/4 Thomas Vander Stichele : > > Thomas Vander Stichele added the comment: > > Maybe I am missing something, but why was it ok for this patch to move > EXTENDED_ARGS from 143 to 145 ? I thought the numbers for opcodes were part > of the ABI ? Very m

[issue6101] SETUP_WITH

Thomas Vander Stichele added the comment: Maybe I am missing something, but why was it ok for this patch to move EXTENDED_ARGS from 143 to 145 ? I thought the numbers for opcodes were part of the ABI ? -- nosy: +thomasvs ___ Python tracker

[issue6101] SETUP_WITH

Benjamin Peterson added the comment: Applied in r72912. -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing

[issue6101] SETUP_WITH

Antoine Pitrou added the comment: SETUP_WITH3.patch looks good to me. -- resolution: -> accepted stage: -> commit review ___ Python tracker ___

[issue6101] SETUP_WITH

Changes by Benjamin Peterson : Added file: http://bugs.python.org/file14062/SETUP_WITH3.patch ___ Python tracker ___ ___ Python-bugs-list maili

[issue6101] SETUP_WITH

Changes by Benjamin Peterson : Added file: http://bugs.python.org/file14061/SETUP_WITH2.patch ___ Python tracker ___ ___ Python-bugs-list maili

[issue6101] SETUP_WITH

Antoine Pitrou added the comment: Endly, in compile.c, it seems the stack effect of SETUP_WITH should be 1, not 3 (only one value is pushed onto the stack). -- ___ Python tracker ___

[issue6101] SETUP_WITH

Benjamin Peterson added the comment: 2009/5/24 Antoine Pitrou : > > Antoine Pitrou added the comment: > > I'm not sure I understand the point of PyInstance_Check() in > lookup_special(). _PyObject_LookupSpecial doesn't understand classic classes. > > You should bump the bytecode version in im

[issue6101] SETUP_WITH

Antoine Pitrou added the comment: I'm not sure I understand the point of PyInstance_Check() in lookup_special(). You should bump the bytecode version in import.c. By the way, there are some "with" tests in pybench (you can run them using "-t With"). -- nosy: +pitrou _

[issue6101] SETUP_WITH

Benjamin Peterson added the comment: Performance numbers: With patch: $ ./python.exe -m timeit -s 'import thread; l = thread.allocate_lock()' 'with l: pass' 100 loops, best of 3: 1.99 usec per loop Without: 10 loops, best of 3: 2.15 usec per loop -- _

[issue6101] SETUP_WITH

New submission from Benjamin Peterson : This patch condenses the many current opcodes used to start a with statement into one, SETUP_WITH. I originally did this to properly lookup __enter__ and __exit__ as special methods. However, the patch also has the nice side effect of removing the need for