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
