make patchcheck should check the whitespace of .c/.h files #53158
Description
Activity
This would be especially useful now that only spaces are used in .c/.h files and not tabs.
Here’s a quick crack at it. Conservative approach: Don’t reindent, just complain.
Updating patch to check header files too. Untested.
Thanks for the patch, Éric. I will get to it when I can.
I may add that although there is no formal test of any kind, I added tabs in two places in one .c file and in one place in another place, and it correctly reported two files. It’s a small function mostly copied from the one above; the only part where I used my brain is the counter (Python did the rest), so it should be ok.
Éric,
It will be helpful if your code could also check for lines longer than 79 characters.
.. and trailing white space.
Replacing VCS hooks, are we? :) Updated and attached.
Ideas for other feature requests:
- Printing the name of files with issues;
- Fail-fast mode or full report.
Nitpick: shouldn't that
len(line) > 79be
len(line) > 80? Either that, or strip the line ending from the line before computing its length.
Similarly, isn't
line[-1].isspace()
always going to be true (well, except possibly at the end of the file), thanks to the line-ending character?
Forgot readling kept the line end, thanks for catching. Updated (yay for Mercurial Queues!)
s/readling/readline/
s/readline/iterating over the file/Sorry to be nitpicky, but:
(a) the line[-2] produces "IndexError: string index out of range" on empty
lines, and(b) this won't detect trailing whitespace on the last line of a file, if there's no newline at the end of the file. Actually, it might also be worth checking that there *is* a newline at the end of the file; this is actually required by the C standards. (E.g., C99 5.1.1.2p2: "A source file that is not empty shall end in a new-line character".)
10 remaining items
Hmm, it looks like patchcheck does not fix trailing whitespace in c files:
$ grep ' $' Modules/datetimemodule.c| cat -ve $ GET_TD_DAYS(offset1) * 86400 - $ Py_DECREF(offset); $ if ((offset1 != offset2) && $ $ $ make patchcheck
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
Usually, copying Modules/Setup.dist to Modules/Setup will work.
-----------------------------------------------
./python.exe ./Tools/scripts/patchcheck.py
Getting the list of files that have been added/changed ... 1 file
Fixing whitespace ... 0 files
Docs modified ... NO
Misc/ACKS updated ... NO
Misc/NEWS updated ... NODid you run the test suite?
Sorry if I was unclear. Out of the four points I listed, this patch only did the refactoring (4). I have another patch to add and use a check_pep7 function, I’ll refresh it and post it.
On Sun, Jul 4, 2010 at 22:40, Éric Araujo <report@bugs.python.org> wrote:
Éric Araujo <merwok@netwok.org> added the comment:
Sorry if I was unclear. Out of the four points I listed, this patch only did the refactoring (4). I have another patch to add and use a check_pep7 function, I’ll refresh it and post it.
You were clear, I just prematurely closed it by accident.
I wonder how to have sane code reuse between patchcheck and Mercurial hooks. Mark seems to have started seconding Dirkjan with hooks, see e.g.
http://hg.python.org/hooks/rev/0344575ad60e, so I wonder if we’re going to use only hooks (pro: they will be invoked on every push, whereas patchcheck is opt-in, con: they would require that contributors clone the hooks repo and set them up) or still maintain patchcheck, which has pros (no setup, does not require a VCS) and cons (not automatic, not widely used, whereas hooks can be part of the new python-dev policy).Note directly related to this issue, but untabify.py fails on files that contain non-ascii characters. For example:
$ ./python.exe Tools/scripts/untabify.py Modules/_heapqmodule.c Traceback (most recent call last): ... (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf8' codec can't decode byte 0xe7 in position 173: invalid continuation byteI am not sure what relevant C standard has to say about using non-ascii characters in comments, but the checking tool should not fail with a traceback in such situation.
I opened bpo-9598 for the untabify bug. For the purposes of source checking, I believe non-ascii characters should be disallowed in python C source code. According to my understanding of C89 standard, interpretation of characters outside of the basic character set is implementation and locale dependent.
The following commit from today is related to this issue: 815b88454e3e
"Remove trailing whitespace in order to silence warnings on HP-UX."
make patchcheckis still herepatchcheck.pyis still around, but whitespace checks have been removed from it (which doesn't run in CI), and added to pre-commit (run in CI), including.cand.hfiles.We also have a EditorConfig file, I recommend enabling this in your editor.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: