New submission from Raymond Hettinger <raymond.hettin...@gmail.com>:
Now that list comprehensions mask run their internals in code objects (the same
way that genexps do), it is getting harder to use dis() to see what code is
generated. For example, the pow() call isn't shown in the following
disassembly:
>>> dis('[x**2 for x in range(3)]')
1 0 LOAD_CONST 0 (<code object <listcomp> at
0x1005d1e88, file "<dis>", line 1>)
3 MAKE_FUNCTION 0
6 LOAD_NAME 0 (range)
9 LOAD_CONST 1 (3)
12 CALL_FUNCTION 1
15 GET_ITER
16 CALL_FUNCTION 1
19 RETURN_VALUE
I propose that dis() build-up a queue undisplayed code objects and then
disassemble each of those after the main disassembly is done (effectively
making it recursive and displaying code objects in the order that they are
first seen in the disassembly). For example, the output shown above would be
followed by a disassembly of its internal code object:
<code object <listcomp> at 0x1005d1e88, file "<dis>", line 1>:
1 0 BUILD_LIST 0
3 LOAD_FAST 0 (.0)
>> 6 FOR_ITER 16 (to 25)
9 STORE_FAST 1 (x)
12 LOAD_FAST 1 (x)
15 LOAD_CONST 0 (2)
18 BINARY_POWER
19 LIST_APPEND 2
22 JUMP_ABSOLUTE 6
>> 25 RETURN_VALUE
----------
components: Library (Lib)
messages: 133478
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Improve disassembly to show embedded code objects
type: feature request
versions: Python 3.3
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11822>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
