[issue31197] Namespace disassembly omits some compiled objects

2017-08-17 Thread Nick Coghlan

Nick Coghlan added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue31197] Namespace disassembly omits some compiled objects

2017-08-15 Thread Nick Coghlan

Nick Coghlan added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue31197] Namespace disassembly omits some compiled objects

2017-08-14 Thread Nick Coghlan

Nick Coghlan added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue31197] Namespace disassembly omits some compiled objects

2017-08-14 Thread Nick Coghlan

New submission from Nick Coghlan:

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)

--
messages: 300234
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Namespace disassembly omits some compiled objects
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com