classification
Title: Enhance dis.dis to autocompile codestrings
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.2
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: ncoghlan Nosy List: benjamin.peterson, daniel.urban, georg.brandl, mark.dickinson, ncoghlan, rhettinger, scott.dial, terry.reedy
Priority: normal Keywords: easy, patch

Created on 2009-07-17 19:06 by terry.reedy, last changed 2010-07-09 15:11 by eric.araujo. This issue is now closed.

Files
File name Uploaded Description Edit
issue6507.diff daniel.urban, 2010-04-11 16:36 Patch (py3k branch)
issue6507_2_priv.diff daniel.urban, 2010-05-08 20:23
issue6507_3.diff daniel.urban, 2010-07-02 18:02
Messages (15)
msg90637 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2009-07-17 19:06
dis.dis(ob) currently accepts "a module, a class, a method, a function,
or a code object." But for most uses I have seen on python-list, people
start with a code snippet. They must then wrap that in a function or
remember (or lookup) a call such as compile(code, '', 'exec') to make a
code object. I propose that dis do the latter automatically. Dis already
has to branch on the input class, so I assume adding another branch
should not be difficult.

On the Python ideas list, Steven D'Aprano raised the issue of 'exec'
versus 'single' versus 'eval'. As far as dis is concerned, there seems
to be no difference between 'exec' and 'single'.

>>> dis(compile('x = x+1', '', 'single'))
  1           0 LOAD_NAME                0 (x) 
              3 LOAD_CONST               0 (1) 
              6 BINARY_ADD           
              7 STORE_NAME               0 (x) 
             10 LOAD_CONST               1 (None) 
             13 RETURN_VALUE         

>>> dis(compile('x = x+1', '', 'exec'))
  1           0 LOAD_NAME                0 (x) 
              3 LOAD_CONST               0 (1) 
              6 BINARY_ADD           
              7 STORE_NAME               0 (x) 
             10 LOAD_CONST               1 (None) 
             13 RETURN_VALUE         

Using 'exec' instead of 'eval' adds two spurious, but easily ignored, lines.

>>> dis(compile('x+1','', 'eval'))
  1           0 LOAD_NAME                0 (x) 
              3 LOAD_CONST               0 (1) 
              6 BINARY_ADD           
              7 RETURN_VALUE    
     
>>> dis(compile('x+1', '', 'exec'))
  1           0 LOAD_NAME                0 (x) 
              3 LOAD_CONST               0 (1) 
              6 BINARY_ADD           
              7 POP_TOP              
              8 LOAD_CONST               1 (None) 
             11 RETURN_VALUE         

Between the current doc sentences "For a single code sequence, it prints
one line per bytecode instruction." and "If no object is provided, it
disassembles the last traceback." I propose adding the following two
sentences.

"Strings are first compiled as statements to code objects with
compile(string,'','exec'). For expressions, this adds a spurious POP_TOP
and LOAD_CONST at the end."

'compile' should be cross-referenced to its listing under built-in
functions.
msg90647 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2009-07-17 22:57
Copying my suggestion (minus examples) over from the python-ideas thread:

We could define it as trying the three modes in order (first 'eval',
then 'single', then 'exec') moving on to the next option if it raises
syntax error:

from dis import dis
def dis_str(source):
  modes = ('eval', 'single', 'exec')
  for mode in modes:
    try:
      c = compile(source, '', mode)
      break
    except SyntaxError:
      if mode is modes[-1]:
        raise
  return dis(c)
msg90670 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-07-18 10:19
As I explained on python-ideas, 'single' should not be tried.
msg90675 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2009-07-18 13:48
As per Georg's suggestion, a better approach would look like:

from dis import dis
def dis_str(source):
  try:
    c = compile(source, '', 'eval')
  except SyntaxError:
    c = compile(source, '', 'exec')
  return dis(c)
msg90892 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2009-07-24 19:56
Trying both 'eval' and 'exec' looks fine to me.
Marking 'easy' because I expect it should be ;-)
msg102851 - (view) Author: Daniel Urban (daniel.urban) * (Python triager) Date: 2010-04-11 16:36
I've made a patch, which adds a disassemble_str function to the dis module. The dis.dis function calls this function if x is a string. Added the following sentence to the documentation: "Strings are first compiled to code objects with the :func:`compile` built-in function." Added two simle unittests.
msg102859 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-04-11 17:56
+1
msg103507 - (view) Author: Daniel Urban (daniel.urban) * (Python triager) Date: 2010-04-18 17:35
Any chance, that my patch will be accepted? Is there a problem with it?

Thanks.
msg105329 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2010-05-08 19:39
disassemble_str should be private with an underscore.
msg105336 - (view) Author: Daniel Urban (daniel.urban) * (Python triager) Date: 2010-05-08 20:23
Done. Attached new patch as issue6507_2_priv.diff.
msg106502 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2010-05-26 02:07
Missed the window for 2.7, but should be right for 3.2.

There's a minor error in the documentation (strings need to be mentioned in the list of acceptable types), but I can fix that on commit.
msg109102 - (view) Author: Scott Dial (scott.dial) Date: 2010-07-02 11:53
> disassemble_str should be private with an underscore.

disassemble_string should've been private as well, while we are editing this module.
msg109119 - (view) Author: Daniel Urban (daniel.urban) * (Python triager) Date: 2010-07-02 18:02
> disassemble_string should've been private as well, while we are editing this module.

Attached the updated patch.
msg109127 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-07-02 20:19
Just today, someone posted the result of dis.dis('somebytes') and did not notice the error because dis blithely disassembles bytes as bytecodes, even in 3.x. (The person actually dissed a 2.x string).

>>> from dis import dis
>>> dis(b'cat')
          0 DUP_TOPX        29793

It is a natural thing to do, so I hope this is put in 3.2. 

Since the undocumented 'disassemble_string' now disassembles bytes, I think it should be renamed '_disassemble_bytes' instead of '_disassemble_string'. This would accord with the general effort to remove 2.x fossils from 3.x.

Aside from that, it looks ready, from a reading review, to apply and test: doc addition, added tests, new function and else case, and rename.
msg109162 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2010-07-03 07:43
Committed (with some minor modifications) in r82471.

Inspired by Yanov Aknin's ssc() tool, I've opened a new RFE (issue 9147) for a similarly enhanced show_code() implementation.
History
Date User Action Args
2010-07-09 15:11:16eric.araujosetresolution: accepted -> fixed
2010-07-03 07:43:11ncoghlansetstatus: open -> closed

messages: + msg109162
stage: patch review -> resolved
2010-07-02 20:28:57eric.araujosetresolution: accepted
stage: commit review -> patch review
2010-07-02 20:19:28terry.reedysetmessages: + msg109127
2010-07-02 18:42:33mark.dickinsonsetnosy: + mark.dickinson
2010-07-02 18:02:47daniel.urbansetfiles: + issue6507_3.diff

messages: + msg109119
2010-07-02 11:53:45scott.dialsetnosy: + scott.dial
messages: + msg109102
2010-05-26 02:07:50ncoghlansetpriority: low -> normal
assignee: benjamin.peterson -> ncoghlan
messages: + msg106502

versions: - Python 2.7
2010-05-08 20:23:23daniel.urbansetfiles: + issue6507_2_priv.diff

messages: + msg105336
2010-05-08 19:39:07benjamin.petersonsetmessages: + msg105329
2010-04-18 17:37:30rhettingersetassignee: benjamin.peterson
stage: needs patch -> commit review

nosy: + benjamin.peterson
versions: + Python 2.7
2010-04-18 17:35:01daniel.urbansetmessages: + msg103507
2010-04-11 17:56:55rhettingersetnosy: + rhettinger
messages: + msg102859
2010-04-11 16:36:03daniel.urbansetfiles: + issue6507.diff

nosy: + daniel.urban
messages: + msg102851

keywords: + patch
2009-07-24 19:56:45terry.reedysetkeywords: + easy

messages: + msg90892
2009-07-18 13:48:53ncoghlansetmessages: + msg90675
2009-07-18 10:19:52georg.brandlsetnosy: + georg.brandl
messages: + msg90670
2009-07-17 22:57:53ncoghlansetnosy: + ncoghlan
messages: + msg90647
2009-07-17 19:07:49benjamin.petersonsetpriority: low
stage: needs patch
2009-07-17 19:06:14terry.reedycreate