[pypy-dev] Re: [pypy-svn] rev 2674 - pypy/trunk/doc

Bengt Richter bokr at oz.net
Mon Dec 22 22:17:03 CET 2003


At 18:07 2003-12-22 +0100, you (holger krekel) wrote:
>Hi Alex,
>
>[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
>mail). 
>
>> 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,
Bengt Richter



More information about the Pypy-dev mailing list