[pypy-dev] Re: [pypy-svn] rev 2674 - pypy/trunk/doc
bokr at oz.net
Mon Dec 22 22:17:03 CET 2003
At 18:07 2003-12-22 +0100, you (holger krekel) wrote:
>[Alex Martelli Mon, Dec 22, 2003 at 05:52:40PM +0100]
>> On Monday 22 December 2003 04:42 pm, holger krekel wrote:
>> > Hi Alex and others,
>> > i think we should try to minimize the number of formatting changes not
>> > only in program code but also in ReST files as it makes reading the diffs
>> > really hard because you basically have to reread the whole document
>> > in order to see the differences. As this has happended now several
>> > times i think it makes sense to think of some convention which allows
>> > the diffs to stay readable.
>> > Maybe (especially) ReST-changes should be done with a two-step approach:
>> > first the one where you can read the content diff and then the one (if
>> > neccessary at all) which has purely formatting changes and says so in
>> > the commit message. And we might also think about a common line width
>> > so that not everybody reformats the text again and again :-)
>> Yes, good points. I think line length of <80, indents of 4 spaces, no tabs,
>> no traling spaces allowed on any line under any pretext whatsoever,
>> would be good conventions; I find it extremely hard to edit files (be they
>> sources, ReST, or any other text) that fail to meet these conventions.
>For python source files this is fine for me. I am not entirely sure for
>ReST especially since you can have verbatim-blocks (say an excerpt from a
>> Is there a way, with subversion, to have a simple conformance test for this
>> kind of formatting parameters be run automatically, whenever a textfile is
>> committed? If files breaking these conventions (or whatever conventions
>> we can all agree on) were never committed, this would minimize the need
>> for "changes that are purely related to formatting", I think.
>Indeed. A pre-commit hook is able to perform checks like this although
>the details might get hairy if you go for "indentation of four-spaces"
>enforcement (e.g. considering docstrings) . I guess i'd go for simplicity
>and just enforce "line-length < 80" and svn:eol-style==native for all *.py
>and *.txt files (unless their svn:mime-type is explicitely non-text or some
>such). Non-conforming commits would simply be refused and nothing would be
>changed on the fly. Opinions?
Comments from left field (since I wound up a mere lurker after all ;-)
1. I could see automated refusal of commits being a nuisance unless there
was an override available.
2. What about a separate pypytidy.py tool that people could use like
a standards-enforcer/beautifier/spell-checker _before_ committing?
Seems like an enforcer-hook would contain much of the logic anyway,
and done separately a useful tool could evolve as a side effect.
Regards & Happy Holidays,
More information about the Pypy-dev