This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: SETUP_WITH
Type: performance Stage: commit review
Components: Interpreter Core Versions: Python 3.2, Python 2.7
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: benjamin.peterson Nosy List: benjamin.peterson, pitrou, rhettinger, thomasvs
Priority: normal Keywords: patch

Created on 2009-05-24 23:31 by benjamin.peterson, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
SETUP_WITH.patch benjamin.peterson, 2009-05-24 23:31
SETUP_WITH2.patch benjamin.peterson, 2009-05-25 00:12
SETUP_WITH3.patch benjamin.peterson, 2009-05-25 01:47
Messages (14)
msg88293 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-05-24 23:31
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 a temporary variable.
msg88294 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-05-24 23:52
Performance numbers:

With patch:

$ ./python.exe -m timeit -s 'import thread; l = thread.allocate_lock()'
'with l: pass'
1000000 loops, best of 3: 1.99 usec per loop

Without:
100000 loops, best of 3: 2.15 usec per loop
msg88295 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-05-24 23:59
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").
msg88296 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-05-25 00:00
2009/5/24 Antoine Pitrou <report@bugs.python.org>:
>
> Antoine Pitrou <pitrou@free.fr> 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 import.c.

Ok

Thanks.
msg88297 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-05-25 00:01
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).
msg88315 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-05-25 09:37
SETUP_WITH3.patch looks good to me.
msg88317 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-05-25 13:14
Applied in r72912.
msg123384 - (view) Author: Thomas Vander Stichele (thomasvs) Date: 2010-12-04 19:23
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 ?
msg123385 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2010-12-04 19:26
2010/12/4 Thomas Vander Stichele <report@bugs.python.org>:
>
> Thomas Vander Stichele <thomasvs@users.sourceforge.net> 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 much not.
msg123389 - (view) Author: Thomas Vander Stichele (thomasvs) Date: 2010-12-04 19:42
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.
msg123390 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-12-04 19:44
> 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, IronPython or even PyPy?
Besides, not only opcode numbers may change, but the semantics of a
given opcode can change too (even if its number stays the same). So
there's nothing stable you can rely on here.
msg123393 - (view) Author: Thomas Vander Stichele (thomasvs) Date: 2010-12-04 19:55
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.110031279 +0100
+++ opcodes-2.7	2010-12-04 20:47:06.770611299 +0100
@@ -10,7 +10,6 @@
   12 UNARY_NOT
   13 UNARY_CONVERT
   15 UNARY_INVERT
-  18 LIST_APPEND
   19 BINARY_POWER
   20 BINARY_MULTIPLY
   21 BINARY_DIVIDE
@@ -73,6 +72,7 @@
   91 DELETE_NAME
   92 UNPACK_SEQUENCE
   93 FOR_ITER
+  94 LIST_APPEND
   95 STORE_ATTR
   96 DELETE_ATTR
   97 STORE_GLOBAL
@@ -82,15 +82,18 @@
  101 LOAD_NAME
  102 BUILD_TUPLE
  103 BUILD_LIST
- 104 BUILD_MAP
- 105 LOAD_ATTR
- 106 COMPARE_OP
- 107 IMPORT_NAME
- 108 IMPORT_FROM
+ 104 BUILD_SET
+ 105 BUILD_MAP
+ 106 LOAD_ATTR
+ 107 COMPARE_OP
+ 108 IMPORT_NAME
+ 109 IMPORT_FROM
  110 JUMP_FORWARD
- 111 JUMP_IF_FALSE
- 112 JUMP_IF_TRUE
+ 111 JUMP_IF_FALSE_OR_POP
+ 112 JUMP_IF_TRUE_OR_POP
  113 JUMP_ABSOLUTE
+ 114 POP_JUMP_IF_FALSE
+ 115 POP_JUMP_IF_TRUE
  116 LOAD_GLOBAL
  119 CONTINUE_LOOP
  120 SETUP_LOOP
@@ -110,4 +113,7 @@
  140 CALL_FUNCTION_VAR
  141 CALL_FUNCTION_KW
  142 CALL_FUNCTION_VAR_KW
- 143 EXTENDED_ARG
+ 143 SETUP_WITH
+ 145 EXTENDED_ARG
+ 146 SET_ADD
+ 147 MAP_ADD
msg123394 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-12-04 19:58
> 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 opcodes in this list.
Regardless, there is no guarantee about opcode numbering stability. You
cannot infer such an expectation from previous behaviour.
msg123395 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-12-04 20:01
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.
History
Date User Action Args
2022-04-11 14:56:49adminsetgithub: 50351
2010-12-04 20:01:17rhettingersetnosy: + rhettinger
messages: + msg123395
2010-12-04 19:58:54pitrousetmessages: + msg123394
2010-12-04 19:55:26thomasvssetmessages: + msg123393
2010-12-04 19:44:46pitrousetmessages: + msg123390
2010-12-04 19:42:18thomasvssetmessages: + msg123389
2010-12-04 19:26:09benjamin.petersonsetmessages: + msg123385
2010-12-04 19:23:12thomasvssetnosy: + thomasvs
messages: + msg123384
2009-05-25 13:14:09benjamin.petersonsetstatus: open -> closed

messages: + msg88317
2009-05-25 09:37:49pitrousetresolution: accepted
messages: + msg88315
stage: commit review
2009-05-25 01:47:28benjamin.petersonsetfiles: + SETUP_WITH3.patch
2009-05-25 00:12:49benjamin.petersonsetfiles: + SETUP_WITH2.patch
2009-05-25 00:01:11pitrousetmessages: + msg88297
2009-05-25 00:00:49benjamin.petersonsetmessages: + msg88296
2009-05-24 23:59:07pitrousetnosy: + pitrou
messages: + msg88295
2009-05-24 23:52:27benjamin.petersonsetmessages: + msg88294
2009-05-24 23:31:35benjamin.petersoncreate