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 terry.reedy
Recipients Saimadhav.Heblikar, Todd.Rovito, cheryl.sabella, markroseman, taleinat, terry.reedy
Date 2017-09-24.02:27:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1506220050.92.0.738538452335.issue20827@psf.upfronthosting.co.za>
In-reply-to
Content
Miscellaneous comments:

1. ClassBrowser.main, changed in Heblikar's  patch and referred to in the discussion, was the predecessor to the current browser._module_browser htest function.

I have not looked at the patch in detail, but it would have to be revised to be applied today.

2. pyclbr.Class and .Function look like public APIs (unlike _Object) and so I presume we must preserve back-compatibility by adding new args at the end of the arg list.

3. Changing pyclbr involves other core devs and possibly permissions and discussions.  If we do patch it, we should also use guaranteed ordered dicts. 3.7.0b1 is expected early next January.

Pyclbr is outdated at least since 3.5 since it ignores 'async'.  (At least that does not cause a following def to be skipped.) It should really have an AFunction subclass or a marker on Function so Module Browser could then prefix 'def' with 'async'. 

4. Bases and abstract arguments are both sequences between ()s.  But for pyclbr and browser, the analogy does not go much further.  Pyclbr tries to replace string names of bases with Class objects.  Browser uses this to prefix bases with paths prior to turning the sequence back to a string.  If it were not for that, having the stuff between ( and ) parsed would be a nuisance.  All browser currently needs is everything between ( and ) as a single string.  Actually, taking annotations into account, everything between ( and :, minus extraneous whitespace.

5. Pyclbr intentionally reads code but does not run it.  Must we keep that feature?  Or should be embrace and extend it?

Except for the current file, IDLE (currently) can only do completions and calltips for code that has been imported (and run) into the current user process.  Could it do as well or better without imports, perhaps by analyzing but not running other code in the IDLE process?

When pyclbr and IDLE were written, the only other no-run option was parsing to a barely readable concrete syntax tree.  Since a decade ago, ast has been available.  I believe that an ast tree contains all the information in a pyclbr tree.  That means that it should be possible to dump all the hand-crafted parsing in pyclbr and re-implement it by extracting the same info from an ast tree, using the ast node visitors.

What I am thinking is that IDLE might use ast for module browser, completions, and calltips.  If you are not familiar with ast, but want to learn, run something like

import ast
code = '''
import itertools as it
class a(it.count):
    def __init__(self, n): pass
    def extra(self, m:int) -> int: pass
'''
tree = ast.parse(code)
for node in ast.walk(tree):  
    print(node)  # This produces same as ast.dump(tree)
    print(node._fields)

and then skim the official doc and look at least this page of the resource recommended at the end.
https://greentreesnakes.readthedocs.io/en/latest/nodes.html#function-and-class-definitions
History
Date User Action Args
2017-09-24 02:27:31terry.reedysetrecipients: + terry.reedy, taleinat, markroseman, Todd.Rovito, Saimadhav.Heblikar, cheryl.sabella
2017-09-24 02:27:30terry.reedysetmessageid: <1506220050.92.0.738538452335.issue20827@psf.upfronthosting.co.za>
2017-09-24 02:27:30terry.reedylinkissue20827 messages
2017-09-24 02:27:28terry.reedycreate