In reviewing the PR for issue 31183, I noticed that the criteria for deciding which values to disassemble when disassembling a namespace (objects with a __dict__ attribute) has gotten out of sync with the criteria used by the dis() itself.

The problem is that dis() checks for particular attributes that may contain code objects, while the recursive descent when processing a __dict__ attribute is based on isinstance() and a predefined list of types.

My proposed remedy for this would be:

1. Factor out a dis._get_code() helper function that returns either None or a compiled code object
2. Base the recursive descent in __dict__ processing on the value either having a __dict__ attribute, or else _get_code() returning a non-None result (in the latter case, the code object itself would be passed to the recursive call, rather than the original value from the namespace)

Note that the current dis._get_code_object() helper doesn't *quite* cover this, as it will implicitly compile raw strings, which isn't the desired behaviour for this use case.

Another refactoring point that came up in the same discussion: it might be nice if the objects that expose code attributes all offered a read-only __code__ property, rather than requiring the dis module (and other consumers) to be aware of all the different object-specific property names.

For ease of reference, I separated out the idea of a common __code__ attribute to its own RFE: https://bugs.python.org/issue31230