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.

Author ncoghlan
Recipients Todd Dembrey, belopolsky, berker.peksag, jleedev, matrixise, ncoghlan, pitrou, rhettinger, serhiy.storchaka, torsten, vstinner
Date 2017-04-15.15:50:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1492271409.93.0.443029802862.issue11822@psf.upfronthosting.co.za>
In-reply-to
Content
+1 for listing the nested code objects after the original one.

In reviewing Serhiy's patch, the core technical implementation looks OK to me, but I think we may want to go with a "depth" argument rather than a simple "recursive" flag.

My rationale for that relates to directly disassembling module and class source code:

- dis(module_source, depth=1) # Module, class bodies, function bodies
- dis(class_source, depth=1) # Class and method bodies

(with the default depth being 0, to disable recursive descent entirely)

Only if you set a higher depth than 1 would you start seeing things like closures, comprehension bodies, and nested classes.

With a simple all-or-nothing flag, I think module level recursive disassembly would be too noisy to be useful.

The bounded depth approach would also avoid a problem with invalid bytecode manipulations that manage to create a loop between two bytecode objects. While the *compiler* won't do that, there's no guarantee that the disassembler is being fed valid bytecode, so we should avoid exposing ourselves to any infinite loops in the display code.
History
Date User Action Args
2017-04-15 15:50:09ncoghlansetrecipients: + ncoghlan, rhettinger, belopolsky, pitrou, vstinner, torsten, berker.peksag, serhiy.storchaka, jleedev, matrixise, Todd Dembrey
2017-04-15 15:50:09ncoghlansetmessageid: <1492271409.93.0.443029802862.issue11822@psf.upfronthosting.co.za>
2017-04-15 15:50:09ncoghlanlinkissue11822 messages
2017-04-15 15:50:09ncoghlancreate