Author ncoghlan
Recipients Todd Dembrey, belopolsky, berker.peksag, jleedev, matrixise, ncoghlan, pitrou, rhettinger, serhiy.storchaka, torsten, vstinner
Date 2017-04-15.17:02:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1492275723.79.0.0795349547505.issue11822@psf.upfronthosting.co.za>
In-reply-to
Content
The problem I see is that we have conflicting requirements for the default behaviour:

- if we modify dis() instead of adding a new function, then the default behaviour needs to be non-recursive for backwards compatibility reasons
- if we allow the depth to be configurable, then we'd like the default behaviour to be to show everything

One potential resolution to that would be to define this as a new function, `distree`, rather than modifying `dis` and `disassemble` to natively support recursion. Then the new function could accept a `depth` argument (addressing my concerns), but have `depth=None` as the default (addressing your concerns).

If we wanted to allow even more control than that, then I think os.walk provides a useful precedent, where we'd add a new `dis.walk` helper that just looked at `co_consts` to find nested code objects without doing any of the other disassembly work.

The dis.walk() helper would produce an iterable of (depth, code, nested) 3-tuples, where:

- the first item is the current depth in the compile tree
- the second is the code object itself
- the third is a list of nested code objects

Similar to os.walk(), editing the list of nested objects in place would let you control whether or not any further recursion took place.
History
Date User Action Args
2017-04-15 17:02:03ncoghlansetrecipients: + ncoghlan, rhettinger, belopolsky, pitrou, vstinner, torsten, berker.peksag, serhiy.storchaka, jleedev, matrixise, Todd Dembrey
2017-04-15 17:02:03ncoghlansetmessageid: <1492275723.79.0.0795349547505.issue11822@psf.upfronthosting.co.za>
2017-04-15 17:02:03ncoghlanlinkissue11822 messages
2017-04-15 17:02:03ncoghlancreate