
<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 20, 2012, at 2:06 PM, Ben Gertzfield <<a href="mailto:bgertzfield@gmail.com">bgertzfield@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Exposes Dmitri's new comment AST introspection APIs ( <a href="http://clang.llvm.org/doxygen/group__CINDEX__COMMENT.html">http://clang.llvm.org/doxygen/group__CINDEX__COMMENT.html</a> ) via the existing Python bindings.<div>

<br></div><div style="">Unit tests included.</div><div><br></div><div style="">Open questions:<br><br></div><div style=""><div style="font-family:arial,sans-serif;font-size:13px">1) For the comment AST methods, they're currently all in one (way-too-large) Comment class.</div>

<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Should I split these into multiple Python classes, or leave them in a flat hierarchy to match the libclang API?</div>

<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Splitting it up may make it easier to read the API, but makes it more fragile when the AST logic changes (and it probably will change over time).</div>

<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Keeping it in one class makes it simpler to handle AST logic changes in the future, but the class is pretty bloated, and has a number of is_foo_type() methods.</div></div></div></blockquote><div><br></div><div>My suggestion is to keep it close to the libclang API, one can always build better abstractions on top.</div><br><blockquote type="cite"><div dir="ltr"><div style="">

<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">2) For the methods that return HTML and XML, should they just return strings, or should I make the API return parser objects? (It seems like introducing a dependency on those modules is probably not the best idea, but I'm not sure what the state of the art is in HTML and XML in Python.)</div></div></div></blockquote><div><br></div><div>Again, I suggest going with simplicity and returning strings, one can utilize the relevant python modules using the string.</div><br><blockquote type="cite"><div dir="ltr"><div style="">

<div><br></div></div></div>

<span><clang-py-comments-v1.patch></span>_______________________________________________<br>cfe-commits mailing list<br><a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits<br></blockquote></div><br></body></html>