Open portante opened 12 years ago
dumpCst as enhanced now makes this obsolete? Now they both do the same thing but I like dumpCst better as one doesn't have to switch on the print stmt inside walkCst.
I think I meant to say in my comment that the print stmt inside walkCst is still useful as one can turn it on to see exactly where the processing breaks. But printCst as a function is no longer needed.
I am not sure it makes it obsolete, as you wrote it does let you see exactly where in the processing it breaks. I'll get to this one a bit later.
printCst function turns off processing so it will print the whole cst regardless (which is also what dumpCst does). What we need is a debug flag that lets you print while processing so you can see when processing stops. What would be really cool is to save some of the processing history in a (circular) buffer that can then be auto dumped whenever the assertion exception is raised! But that would be a feature that would hopefully be rarely needed unless you plan a lot more work on pycscope. And if you do plan on a lot more features to come I really think you should take a look at the AST grammar.
What features are you thinking about that would require the Abstract Syntax Tree to get correctly?
Obviously anything that can be done in AST can also be done in CST so it is not required but it works at a level that fits what you are working to achieve better than CST. For example if we were using AST, firstly we never had to have a problem with assignment detection:
stmt = FunctionDef(identifier name, arguments args, stmt* body, expr* decorator_list) | ClassDef(identifier name, expr* bases, stmt* body, expr decorator_list) ... | Assign(expr\ targets, expr value) | AugAssign(expr target, operator op, expr value) ...
So you immediately get Assign/AugAssign. Then you look at expr:
expr = BoolOp(boolop op, expr* values) | BinOp(expr left, operator op, expr right) ... | Call(expr func, expr* args, keyword* keywords, expr? starargs, expr? kwargs) ... -- the following expression can appear in assignment context | Attribute(expr value, identifier attr, expr_context ctx) | Subscript(expr value, slice slice, expr_context ctx) | Name(identifier id, expr_context ctx) | List(expr* elts, expr_context ctx) | Tuple(expr* elts, expr_context ctx)
You have Call/Attribute/Subscript/Name/Tuple ... all given to you with the right context was well. The cst decoding right now seems to be trying to do what AST would have given you for free, but it is unlikely as complete as and as correct as the AST.
I agree if the current cst decoding is working well there is no need for the extra work to move to ast. That is why I qualified my suggestion with your development intentions.
On Wed, Sep 19, 2012 at 9:31 PM, Peter Portante notifications@github.comwrote:
What features are you thinking about that would require the Abstract Syntax Tree to get correctly?
— Reply to this email directly or view it on GitHubhttps://github.com/portante/pycscope/issues/10#issuecomment-8716560.
The requirement for cscope is that every line of a source file that has a symbol on it appears in the cscope database.
If the AST can provide that, than it can be used in place of the CST.
That said, retooling to use AST seems like a lot of work, so I would only suggest we engage in that effort if there is a feature that would benefit from it.
Do you have any in mind?
Feature wise I am happy with the way it is. I am also no expert on cscope so I am not aware of the requirement you just mentioned. Good to know. If no more difficult bugs pop up I would agree that it is best to keep things the way they are.
On Thu, Sep 20, 2012 at 5:03 PM, Peter Portante notifications@github.comwrote:
The requirement for cscope is that every line of a source file that has a symbol on it appears in the cscope database.
...
From Free Speech: