I am fine with reformatting the python code as well. BTW, does anyone know if autopep8 (or something similar) has some editor or git integration, in a similar way that clang-format does? It would be great if we could make sure any new code added after that still follows the conventions.
cheers, pl On 18 August 2016 at 19:15, Kate Stone <k8st...@apple.com> wrote: > 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 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 k8st...@apple.com > Xcode Low Level Tools > > On Aug 15, 2016, at 8:50 AM, David Jones via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > On Mon, Aug 15, 2016 at 2:36 AM, Pavel Labath via lldb-dev > <lldb-dev@lists.llvm.org> 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/ > > 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 <jing...@apple.com> wrote: >> > >> >> On Aug 12, 2016, at 5:23 AM, Pavel Labath via lldb-dev >> >> <lldb-dev@lists.llvm.org> wrote: >> >> >> >> On 12 August 2016 at 00:54, Chris Lattner via lldb-dev >> >> <lldb-dev@lists.llvm.org> 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 >> >> lldb-dev@lists.llvm.org >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
