If there’s consensus on a reasonable automated formatting solution for Python then I’m fine with going ahead and doing so at the same time. The PEP-8 standard would leave Python code with 4-space indentation, and impart a consistent look to our code. Earlier this week I verified that our current repository builds and passes tests cleanly under the following conditions:
LLVM-style default .clang-format specified at the root of the tree: BasedOnStyle: LLVM Formatting disabled using .clang-format in packages/Python/lldbsuite. It’s not just a matter of comment style and location driving tests. The tests themselves are exercising debugging functionality driven by debug information line tables. Debugging behavior can and will change when using line-oriented requests (breakpoint on a particular line, step over a particular line, etc.): DisableFormat: true # Disabling formatting doesn't implicitly disable include sorting SortIncludes: false Formatting automatically applied for all .c, .h, and .cpp sources in the tree I’ll run the full suite again following reformatting using autopep8 <https://pypi.python.org/pypi/autopep8> for all .py files. Thanks to everyone who has chimed in with suggestions, and with contributions to ensure that include ordering doesn’t become an issue on other platforms. Kate Stone [email protected] <mailto:[email protected]> Xcode Low Level Tools > On Aug 15, 2016, at 8:50 AM, David Jones via lldb-dev > <[email protected]> wrote: > > On Mon, Aug 15, 2016 at 2:36 AM, Pavel Labath via lldb-dev > <[email protected] <mailto:[email protected]>> wrote: > I've sampled the python code from the llvm repository, and it seems to > be using a mixture of 4-, 2-, and even 8- character indent, with 4 > being the most prevalent. So, I think we can safely stay with status > quo. > > > (Comment from the peanut gallery...) > > Python does have a language-level style guide (PEP-8): > > https://www.python.org/dev/peps/pep-0008/ > <https://www.python.org/dev/peps/pep-0008/> > > If code is going to be reformatted, then it may be best to try to converge on > exactly the PEP-8 style. Speaking as a project "outsider" (i.e., not an > active contributor), but someone with Python background, anything that > diverges from standard Python style seems jarring (at least to me). > > > It will take some editor tweaking to make it use the correct indent > for different files, but it should be manageable. > > pl > > On 12 August 2016 at 18:13, Jim Ingham <[email protected] > <mailto:[email protected]>> wrote: > > > >> On Aug 12, 2016, at 5:23 AM, Pavel Labath via lldb-dev > >> <[email protected] <mailto:[email protected]>> wrote: > >> > >> On 12 August 2016 at 00:54, Chris Lattner via lldb-dev > >> <[email protected] <mailto:[email protected]>> wrote: > >>> I recommend approaching this in three steps: > >>> > >>> 1) get the less-controversial changes done that Greg was outlining. > >>> 2) start a discussion in the llvm community about the concept of a > >>> member/global prefix. > >>> 2a) the community could agree that llvm-as-a-whole should move to prefixes > >>> or otherwise change the camel case policy. > >>> 2b) the community could agree that the existing policies are preferred > >>> 3) LLDB moves to whatever is the end result of the discussion. > >>> > >>> I guess what I’m saying is that since the opinions about this are very > >>> strong, and because we haven’t really had that debate in the LLVM > >>> community, > >>> that it would be bad to proactively move to the LLVM style, simply to have > >>> to move back later. Iff the (sure to be extensive) community discussion > >>> settles on the idea that prefixes are the wrong thing, then LLDB should > >>> remove them to be consistent. > >>> > >>> -Chris > >> > >> +1 > >> > >> > >> > >> In terms of the formatting of tests, I did some more research on this. > >> I think the changes needed to be made to the test suite are generally > >> trivial to fix (e.g. r278490), but I don't think we can avoid a manual > >> intervention. CommentPragmas does not seem to be a silver bullet -- it > >> does prevent clang-format from breaking the comment, but it does not > >> prevent it from moving the whole comment to a new line. That said, > >> when I reformatted the test sources with CommentPragmas set, the > >> number of failures went down to 80 (from about 150)... > >> > >> I believe we should still perform the reformatting of the tests, at > >> least to standardize on the 2 space indent (in fact we should consider > >> doing the same for the python code as well, I don't know what's the > >> situation there in llvm land), but it can be done later. It will make > >> the period while the code is in flux longer, but hopefully not too > >> long. Also the modifications will be independent of the main reformat, > >> so it will still be true that a single source file only got > >> reformatted once. > >> > > > > My eyes put in a vote for not reformatting the Python to 2 space tabs. In > > C++, most IDE's do smart things with double-clicking on { to find the > > closing ones easing the task that two space indents makes somewhat harder. > > But since the spacing is the only nesting indicator in Python, it would be > > nice to keep that more visually apparent. > > > >> pl > >> _______________________________________________ > >> lldb-dev mailing list > >> [email protected] <mailto:[email protected]> > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> > > > _______________________________________________ > lldb-dev mailing list > [email protected] <mailto:[email protected]> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> > > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________ lldb-dev mailing list [email protected] http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
